SVNなどのワークロードの元のボリュームでFlexCache 処理が低速化しています

• ONTAP 9.5以降
• FlexCache
• NFSv3
• NLM
• 読み取り専用のNFSエクスポートポリシーを使用するFlexCache キャッシュボリューム

• NLMロックがハングし、待機中の名前変更操作の背後でキューに登録されます
• ワークロードは SVNリポジトリ で、GITの機能と非常によく似た コードをホストします
• 名前変更のレイテンシが数秒から数十秒で上昇しています
  • 注意 :名前変更は主な原因 ですが、ファイルシステムを変更する操作(書き込み、設定属性、削除など)は原因 になります
• straceLinuxクライアントでは、ハングした処理は名前変更とみなされます
• 元のボリュームに対する複数のアクセスと、キャッシュボリュームの読み取り処理が同時に同じファイルに対して複数のアクセスを行った場合

例： NFS用に名前変更を停止したことが原因で発生するレイテンシ問題 を示す行が、出力に表示されます

[ +0.001852] task:svn state:D stack: 0 pid:61131 ppid: 46494 flags:0x00000004 [ +0.000001] Call Trace: [ +0.000011] ? __rpc_wait_for_completion_task+0x30/0x30 [sunrpc] [ +0.000001] __schedule+0x3fa/0x740 [ +0.000007] ? __rpc_wait_for_completion_task+0x30/0x30 [sunrpc] [ +0.000000] schedule+0x4b/0xb0 [ +0.000006] rpc_wait_bit_killable+0x24/0xa0 [sunrpc] [ +0.000000] __wait_on_bit+0x6e/0xa0 [ +0.000011] out_of_line_wait_on_bit+0x8e/0xb0 [ +0.000001] ? init_wait_var_entry+0x50/0x50 [ +0.000005] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc] [ +0.000008] nfs_rename+0xbc/0x2e0 [nfs] [ +0.000005] vfs_rename+0x681/0x920 [ +0.000004] ? lookup_dcache+0x44/0x70 [ +0.000004] do_renameat2+0x494/0x530 [ +0.000004] ? do_renameat2+0x494/0x530 [ +0.000004] __x64_sys_rename+0x20/0x30 [ +0.000004] do_syscall_64+0x37/0x80 [ +0.000004] entry_SYSCALL_64_after_hwframe+0x44/0xa9

例：

• SVNでは、 current という名前のファイルにNLMロックを設定することで、（現在のSVNリポジトリバージョンを知っているために使用される）という名前のファイルを保持するためにファイルロックを使用します write-lock
• vserver lock showwrite-lockファイルの例を次に示します

Cluster::> vserver lock show -vserver svm0 -volume nfs -path /vol2/svn/write-lock -fields   bytelock-offset,client-address,bytelock-length,lock-state
vserver volume lif   lif-id path                 lock-state bytelock-offset bytelock-length      client-address
------- ------ ----- ------ -------------------- ---------- --------------- -------------------- --------------
svm0    nfs    lif_1 1026   /vol2/svn/write-lock granted    0               18446744073709551615 10.1.2.3