Centos
CentOS 7 上的 NFS/RDMA，小文件損壞
在 HPC 環境中，我們有 2 個節點系列，一個執行 7.1.1503（核心
3.10.0-229.el7.x86_64），另一個執行較新的 7.7.1908（核心3.10.0-1062.12.1.el7.x86_64）。兩者都使用以下供應商 (Mellanox) 記錄的標誌安裝NFS/RDMA伺服器：10.0.0.1:/pool0/home on /mnt/rdma type nfs (rw,relatime,sync,vers=3,rsize=262144,wsize=262144,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,nocto,noac,proto=rdma,port=20049,timeo=600,retrans=2,sec=sys,mountaddr=10.0.0.1,mountvers=3,mountproto=tcp,local_lock=none,addr=10.0.0.1)在 7.1 節點上，我可以執行以下操作：
7.1$ dd if=/dev/zero of=/mnt/rdma/test bs=1 count=701在 7.7 節點上，我將收到完全預期的文件
7.2$ hexdump /mnt/rdma/test 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00002b0 0000 0000 0000 0000 0000 0000 0000 00002bd現在，如果我用700 字節或更少的字節進行相同的測試，則文件已損壞：
7.1$ dd if=/dev/zero of=/mnt/rdma/test bs=1 count=7007.2$ hexdump /mnt/rdma/test | head -10 0000000 9dfe a757 0000 0100 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0100 0000020 0000 0100 0000 a401 0000 0100 0000 0000 0000030 0000 0000 0000 0000 0000 bc02 0000 0000 0000040 0000 0002 0000 0000 0000 0000 168c 0083 0000050 4a0f c612 0000 0000 b000 5a5b 1262 1e75 0000060 9d04 bc90 1262 1a75 c233 50e9 1262 1a75 0000070 c233 50e9 0000 bc02 0000 0100 0000 bc02 0000080 0000 0000 000a 5b5a 00b0 0000 0f9d 030c 0000090 0000 2d00 0000 0000 0000 0000 0000 0000使用 NFS over TCP 而不是 RDMA 嘗試相同的命令時，文件不會損壞。
我們已經嘗試了很多很多的
mount選項，調整rsize等等wsize，並且已經沒有想法了，很高興有一些新的……是的，升級到更新的核心顯然已經擺在桌面上，但我還不確定這在短時間內是可行的。
請注意，舊節點不適用於 7.7，而較新的節點不適用於 7.1。
更新
就像建議的那樣，我已經升級到最新的 CentOS 7 版本，而且，這個錯誤仍然存在。
node1# dd if=/dev/zero of=/mnt/rdma/1160 bs=1 count=700node2# uname -mr 3.10.0-1160.53.1.el7.x86_64 x86_64 node2# lsb_release -d Description: CentOS Linux release 7.9.2009 (Core) node2# hexdump /mnt/rdma/1160|head -5 0000000 376b 1728 0000 0100 0000 0000 0000 0000 0000010 0000 0000 0000 0000 0000 0000 0000 0100 0000020 0000 0100 0000 a401 0000 0100 0000 0000 0000030 0000 0000 0000 0000 0000 bc02 0000 0000 0000040 0000 0002 0000 0000 0000 0000 168c 0083更新 2
我剛剛在同一個節點上做了一個測試，最近的一個，升級到CentOS 7.9，在同一個節點讀寫時實際上失敗了。
此外，使用 調整
/proc/sys/sunrpc/rdma_memreg_strategy會產生非常奇怪的結果，例如rdma_memreg_strategy == 6雜訊看起來像這樣：0000120 8898 123d 4506 c0f8 b0d6 3940 44b9 c0f8 0000130 bc92 ba64 4491 c0f8 165c 0ae4 448e c0f8 0000140 c82e 19e7 44a9 c0f8 2ddc 11f2 44dc c0f8 0000150 ad84 79aa 4520 c0f8 b4af 68ca 4571 c0f8 0000160 b752 b3ef 45cb c0f8 b04a 97b8 462d c0f8 0000170 7543 d694 4695 c0f8 d5dd 2cdc 4702 c0f8 0000180 a9bb f717 476e c0f8 4a78 13d9 47d7 c0f8 0000190 2a26 a9e4 4834 c0f8 71c8 3d91 4882 c0f8 00001a0 fcae 8d55 48bb c0f8 2b04 bcf8 48dd c0f8 00001b0 b04c a4be 48e8 c0f8 79d3 db6c 48dc c0f8 00001c0 9f84 c912 48bb c0f8 096c b285 4886 c0f8 00001d0 f0ff ee8e 483e c0f8 d171 e773 47e4 c0f8 00001e0 8e7b f3d1 4779 c0f8 4bbd d26f 46ff c0f8更新 3
我安裝了 Mellanox 的官方驅動程序。現在損壞發生在文件 < 640 字節…
更新 4
嗯，實際上比我想像的還要糟糕。這些文件不僅僅是“損壞”，它們是實際的記憶體洩漏：
# cat 20220222-1 0000000: b449 1fc1 0000 0001 0000 0000 0000 0000 .I.............. 0000010: 0000 0000 0000 0000 0000 0000 0000 0001 ................ 0000020: 0000 0001 0000 01a4 0000 0001 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0258 0000 0000 ...........X.... 0000040: 0000 0200 0000 0000 0000 0000 8c16 8300 ................ 0000050: 0f4a 12c6 0000 0000 00b0 5fd3 6214 a09b .J........_.b... 0000060: 0c5f 0ffa 6214 a088 0f67 27e3 6214 a088 ._..b....g'.b... 0000070: 0f67 27e3 0000 0258 0000 0001 0000 0258 .g'....X.......X 0000080: 0000 5c9a 0000 0000 0000 0000 0000 0020 ..\............ 0000090: 0100 0601 c612 4a0f 0083 168c 0000 0000 ......J......... 00000a0: 0000 0000 0a00 fd56 b000 0000 6d9c 0903 .......V....m... 00000b0: 0000 0000 3d33 8000 0000 011a 0000 0002 ....=3.......... 00000c0: 0000 011a 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d ....------------ 00000d0: 0a0a 0a0a 0a2d 2d2d 2d2d 2d2d 2d2d 2d2d .....----------- 00000e0: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d ---------------- 00000f0: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2049 -------------- I 0000100: 7465 7261 7469 6f6e 2038 3438 3928 2020 teration 8489( 0000110: 2035 2920 202d 2d2d 2d2d 2d2d 2d2d 2d2d 5) ----------- 0000120: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d ---------------- 0000130: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 0a0a 0a20 ------------... 0000140: 2020 2050 4f54 4c4f 4b3a 2020 6370 7520 POTLOK: cpu 0000150: 7469 6d65 2020 2020 302e 3033 3532 3a20 time 0.0352: 0000160: 7265 616c 2074 696d 6520 2020 2030 2e30 real time 0.0 0000170: 3334 390a 2020 2020 5345 5444 494a 3a20 349. SETDIJ: 0000180: 2063 7075 2074 696d 6520 2020 2030 2e30 cpu time 0.0 0000190: 3332 383a 2072 6561 6c20 7469 6d65 2020 328: real time 00001a0: 2020 302e 3033 3239 0a20 2020 2045 4444 0.0329. EDD 00001b0: 4941 473a 2020 6370 7520 7469 6d65 2020 IAG: cpu time 00001c0: 2020 332e 3139 3638 3a20 7265 616c 2074 3.1968: real t 00001d0: 696d 6520 2020 2033 2e31 3938 310a 0000 ime 3.1981... 00001e0: 3131 3238 2020 2020 0a48 4352 2020 2020 1128 .HCR 00001f0: 2020 2020 2020 2020 2038 320a 2020 2020 82. 0000200: 2031 322e 3934 3834 3732 3233 2020 2020 12.94847223 0000210: 2020 2020 2d34 2e31 3938 3830 3635 3138 -4.198806518 0000220: 2020 2020 2020 2020 302e 3933 3536 3336 0.935636 0000230: 3039 3935 2020 2020 0a20 2020 3133 2e33 0995 . 13.3 0000240: 3837 3634 3434 3334 3120 2020 2020 2020 876444341 0000250: 322e 3732 3939 3339 2.729939
因此，經過一周的尋找漏洞後，我提出了一個非常簡單的更新檔。
核心模組中肯定存在一個錯誤
rpcrdma，當數據小於或等於某個大小時，它不會將其分成塊並內聯處理。這個處理有一個我找不到的錯誤，但一個簡單的修復是將所有文件作為塊處理，只需始終0從rpcrdma_results_inline()函式返回。我已經聯繫了驅動程序的作者，並在RedHat 的 Bugzilla上打開了一個安全漏洞。
執行 CentOS-7.9，我無法重現您的問題。
[tru@gpulab00 ~]$ uname -r 3.10.0-1160.45.1.el7.x86_64 [tru@gpulab00 ~]$ mount|grep tru 10.0.1.2:/master/home/tru on /master/home/tru type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=rdma,port=20049,timeo=600,retrans=2,sec=sys,local_lock=none,addr=10.0.1.2) [tru@gpulab00 ~]$ dd if=/dev/zero of=test bs=1 count=700 700+0 records in 700+0 records out 700 bytes (700 B) copied, 0.00286438 s, 244 kB/s [tru@gpulab00 ~]$ hexdump test 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00002b0 0000 0000 0000 0000 0000 0000 00002bc在另一個客戶端上讀取相同的文件：
[tru@gpulab03 ~]$ uname -r 3.10.0-1160.45.1.el7.x86_64 [tru@gpulab03 ~]$ hexdump test 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00002b0 0000 0000 0000 0000 0000 0000 00002bc [tru@gpulab03 ~]$