nfsではなくローカルで実行されているrm -rfを使用する方が良いですか?


10

ディレクトリ上で実行する前に、ディレクトリがあるマシンrm -rf、またはrm -rfNFS 上のディレクトリだけでログインすると、時間に大きな違いがありますか?

回答:


11

もちろん、sshの方が優れています。

NFSは、さまざまなリモートプロシージャコールとデータ同期待機時間を持つ複雑なネットワークプロトコルを使用します。sshの場合、これらは適用されません。

さらに、多くのロックがあります。nfsでのファイル削除は次のように機能します。

  1. あなたのrmコマンドはunlink()syscall を与えます
  2. nfsドライバーはそれをsunrpc要求に変換し、nfsサーバーに送信します
  3. nfsサーバーはこのsunrpc要求をunlink()呼び出しに変換します
  4. このunlink()呼び出しをリモート側で実行します
  5. 成功した後、クライアントに「大丈夫です、完了しました」に相当するrpc応答メッセージを返します
  6. クライアント側のカーネルドライバーは、これをunlink()元の呼び出しの終了コード0に変換します。rm
  7. rm 次のファイルまで反復し、goto 1

さて、重要なことは:2-7の間、rm待つ必要があります。次のunlink()呼び出しを非同期に送信できますが、イベント指向のツールではなく、シングルスレッドです。それができたとしても、トリッキーなnfsマウントフラグが必要です。結果が得られなくなるまで待ちます。

NFS-と任意のネットワークファイルシステム-は常にずっと遅いです。


多くの場合、トリックを使用して再帰的に削除を準無限の速度で行うことができます。

  1. まず、ディレクトリを別の名前に移動します(mv -vf oldfilms oldfilms-
  2. バックグラウンドで削除(rm -rf oldfilms- &

多くの(すべてではない)側面から、このディレクトリの削除は、実際にはゼロ時間で行われたかのように見えます。


拡張子: @ el.pascadoが彼の優れたコメントで言及しているように、実際には2-7はすべてのファイルに対して3xを実行する必要があります。

  • ファイルかディレクトリか(lstat()syscallを使用)かどうかを判断するには、
  • その後、それに応じてください。通常のファイルunlink()の場合、ディレクトリの場合は、その中のopendir()すべてのファイル/ディレクトリを再帰的に削除してからclosedir()、最後にrmdir()
  • 最後に、readdir()呼び出しで次のディレクトリエントリまで反復します。

これには、ファイル用に3つのnfs RPCコマンドが必要であり、ディレクトリ用にさらに3つ必要です。


2
nfsの場合はさらに悪いです。質問が-rフラグに言及しrmているように、最初にファイルが(lstatnfsを介して)ディレクトリであるかどうかを確認し、(nfsを介して)開きopendir、その内容を(readdirnfsを介して)読み取ってから、内部で見つかったすべてのファイルに対して回答で説明されているように実際の削除を実行する必要があります。サブディレクトリに再帰し、(closedirnfsを介して)ディレクトリを閉じてから、見つかったすべてのディレクトリに対して繰り返します。
el.pescado 2017

5

はい。まあ、多分。場合によります。ファイルとディレクトリの数が少ない場合は、それほど大きな違いはありません。

NFSマウントされたディレクトリでファイル操作を一括で実行すると、時間がかかります。NFSサーバー自体にログインし、実際のディレクトリでそれらを実行する機会がある場合、これはより速くなります。

CVSからチェックアウトしてNFS経由でマウントしたOpenBSDポートコレクションを削除してテストしてみましょう。

NFSサーバー:

$ cd /export/shared/ports

$ du -hs .
2.6G    .

$ find . | wc -l
  179688

$ time rm -rf /export/shared/ports/*
0m20.87s real     0m00.12s user     0m04.62s system

クライアント上(バックアップから元のファイルを復元した後):

$ time rm -rf /usr/ports/*
6m49.73s real     0m01.55s user     1m08.96s system
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.