ops/storage: Fmt fix for #nfs-client-other

Author: taoky

docs/ops/storage/network.md

@@ -366,23 +366,23 @@ NFS 尽管使用起来像本地文件系统，但是实际上仍然存在一些
     * **导致的问题**：当运行在用户命名空间内的容器尝试在 NFS 挂载的目录中执行文件所有权变更操作（例如 `chown`命令），并试图将文件所有者设置为一个仅在该容器的用户命名空间内有效的 UID 时，NFS 服务器通常无法识别或正确处理这个来自特定命名空间的 UID。这是因为 NFS 服务器期望的是其自身（或全局）认知范围内的 UID。此类操作因此常常失败。一个典型的场景是，尝试将 Rootless Podman 的存储位置设置在 NFS 挂载的目录上时会遇到困难，如 [Rootless Podman and NFS](https://www.redhat.com/en/blog/rootless-podman-nfs) 中所述。
     * **Workaround**: 使用用户态的 NFS 服务器（如 `nfs-ganesha`）可以在一定程度上缓解这个问题，因为它可以更灵活地被修改。虽然 `nfs-ganesha` 本身并不支持用户命名空间，但是可以应用 [这个 Patch](https://gist.github.com/zeyugao/754edc3572fcd56e3140242e2352eafb) 来使其支持用户命名空间。具体的实现方式可能不够安全，因此需要谨慎使用。这个 patch 基于的假设是 NFS 服务端的 `/etc/subuid` 和 `/etc/subgid` 与 NFS 客户端上的 `/etc/subuid` 和 `/etc/subgid` 是一致的。至少是想要处理的用户对应的 subuid/subgid 是一致的。所以并不需要 NFS 客户端做出改动。在服务端修改为 nfs-ganesha 的实现的时候，之前使用 Kernel NFS Server 提供的挂载目录需要重新挂载。因为 Kernel NFS 的 knfsd_fh 与 ganesha 的 `nfs_fh4` 不兼容。
 
-    `nfs-ganesha` 期望 `fh_version` 为 `GANESHA_FH_VERSION`
-    
-    ```c
-    } else if (pfile_handle->fhversion !=
-				   GANESHA_FH_VERSION) {
-				LogInfo(COMPONENT_FILEHANDLE,
-					"INVALID HANDLE: not a Ganesha handle, fhversion=%d",
-					pfile_handle->fhversion);
-    ```
-    
-    其定义是
-
-    ```c
-    #define GANESHA_FH_VERSION 0x43
-    ```
-
-    而 Kernel NFS Server 的 `knfsd_fh` 结构体中 `fh_version` 的值为 1。导致了不兼容。
+        `nfs-ganesha` 期望 `fh_version` 为 `GANESHA_FH_VERSION`：
+        
+        ```c
+        } else if (pfile_handle->fhversion !=
+                    GANESHA_FH_VERSION) {
+                    LogInfo(COMPONENT_FILEHANDLE,
+                        "INVALID HANDLE: not a Ganesha handle, fhversion=%d",
+                        pfile_handle->fhversion);
+        ```
+        
+        其定义是：
+
+        ```c
+        #define GANESHA_FH_VERSION 0x43
+        ```
+
+        而 Kernel NFS Server 的 `knfsd_fh` 结构体中 `fh_version` 的值为 1，导致了不兼容。
 
 ## iSCSI