(cpとrmの代わりに)mvを使用するとどのような危険がありますか?

(cpとrmの代わりに)mvを使用するとどのような危険がありますか?

私は大学のLinuxクラスター研究グループにアクセスできる大学院生です。長年にわたって私はかなり多くのディレクトリを蓄積してきました。 「フォルダ」はWindows/Mac用語のようですが? - 私のホームディレクトリ(~)にあります。新しいシミュレーションを実行するときは、を使用してホームディレクトリに新しいディレクトリを作成し、そのディレクトリmkdirでシミュレーションを実行します。

しかし、時間が経つにつれて、私は私のホームディレクトリにこれらのディレクトリをたくさん蓄積しました。今、いくつかのディレクトリをサブディレクトリに移動したいと思います。たとえば、という名前の新しいディレクトリを作成してから、、simulations1_10...ディレクトリをそのディレクトリに移動して、simulation1ホームsimulation2ディレクトリsimulation10のルートをより体系的に構成できます。

これには次のものを使用できますcp

cp -r simulation1/ simulations1_10/

simulation1ディレクトリ(およびすべての内容)をディレクトリにコピーしますsimulations1_10。これで削除できますsimulation1

しかし、私の移籍はいいえファイルシステムの境界を超える場合mvも同様です。たくさんより速いcp...(mvもちろん削除ステップも避けることができます.)

mv simulation1/ simulations1_10/

このトリックはすばやく実行されます(とは異なり、基本的にcp再帰mv的に実行されます)。 ~によるとこの回答到着この問題mv「各ディレクトリのinodeデータベースのみを更新する」ので、はるかに高速です。

私の質問はそれを使うのにどんな危険がありますかmv

転送がmv中断されると(停電、ユーザーがCtrl+キーを押すCなどして)、ソースからファイルが破損する可能性があるというリスクがあると思います。そして目的地。そうですか?

また、使用するとmv たくさん、「Inodeデータベース」が頻繁に更新され、ディスクの断片化やその他のハードドライブ/ファイルシステムの問題が発生する可能性がありますか?

答え1

機能rename(コマンドの基礎mv「mvユーティリティは、rename()関数と同じことを行う必要があります。」)はアトミックです(POSIXを参照)。http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html、C標準参照):

一般ファイルの場合、この rename() 関数は ISO C 標準で定義された関数と同じです。ここにインクルードは、ディレクトリに対するアクションを含めるように定義を拡張し、新しいパラメータがすでに存在するファイルに名前を付けるときの動作を指定します。仕様では、関数操作はアトミックでなければなりません。

(ただし、次の警告を参照してください。https://unix.stackexchange.com/a/322074/88983.)

Ctrl-Cなどで操作を中断しても、ファイルを部分的に転送してはいけません。実際に述べたように、単一のファイルシステムはmv実際にファイルの内容をコピーせずにファイルメタデータのみをコピーします。この点で起こりうる最悪の状況は、部分的な動きを見ることです。目次(これにより、通常のファイルが部分的に移動されるのではなく中断される可能性があり、たとえばに移動mv a b c destしますが、すべてのファイルとその内容は正しく移動されます。)adest

問題のinodeの側面に関しては、これが一般的に問題にならないと言いたいと思います。いくつかのディレクトリだけを移動するためにinodeを更新することは、オーバーヘッドの低い日常的な作業です(同じファイルシステムで発生するファイルの内容を書き込む必要があります)。特定のファイルシステムの種類に応じて、潜在的なパフォーマンスの影響または断片化の原因)。

関連情報