とmount --bind /a入力する/bと、mv /a/bigfile /b/時間がかかります (ソース ファイルが大きい場合)。これは、単にファイルシステムのファイル テーブルを更新するのではなく、実際にファイルをコピーしてからソース ファイルを削除します。
仕組みと理由は理解していますmount --bind。他の人が指摘しているように、それについては良い説明がいくつかあります。
mount --bind同じファイルシステム内にあることをマウントに伝え、このような操作 (移動) が実際にファイルシステムのファイル テーブルを更新することによって実行されるようにする方法はありますか?
私はこの問題を理解する方法ではなく、解決方法を尋ねています。おそらく、私が知らないカーネル パッチがすでに利用可能であったり、まだ見つけていない不足しているパラメーターがあったりするのでしょう (など)。
理由: 現在のセットアップでは、 のみをサポートするサービス (nextcloud) がありますmount --bind。シンボリックリンクは使用できません。たとえば、nextcloud の各アカウント内に共有フォルダーが必要な場合は、bind を使用する必要があります。ファイルシステム/カーネル レベルで作成されたものであれば、nextcloud で機能するソリューションであれば何でも受け入れることができます。これは、現在のセットアップでは、ssh などの他の方法でこれらのファイルにアクセスできるためです。言い換えると、任意のコマンドまたはアプリケーションを使用して、例のようにファイルを移動できるようにしたいと考えています。
答え1
どうやらそうではないようだが、マニュアルページrename(2)次のように述べています。
EXDEV古いパスそして新しいパス同じマウントされたファイルシステム上にありません。(Linux では、ファイルシステムを複数のポイントにマウントできますが、rename()同じファイルシステムが両方のマウントポイントにマウントされている場合でも、異なるマウントポイント間では動作しません。)
私の記憶が正しければ、バインド マウントは同じファイル システムを複数回マウントするのと同じです。つまり、事後のバインドには「ソース」と「ターゲット」はありません。
他にも答え数か月前に同じテーマで投稿された別の質問です。この質問にはカーネル開発者との議論へのヒントがあります。ぜひ賛成票を投じてください。
答え2
Docker コンテナ内の nextcloud と samba でも同じ問題が発生しています。すべてのデータを nextcloud 内に移動し、他のユーザーがこのボリュームからバインド マウントできるようにすることで解決しました。
したがって、どのサービスの観点から見ても、MV は常に 1 つのバインド マウント内にのみ存在します。
これが役に立つかどうかは分かりませんが
答え3
rsync代わりにを使用するとmv問題は解決するはずです。次のコマンドを試してください。
rsync -avP /a/bigfile /b/bigfile
問題は、 の視点がmount --bindカーネル内にあり、 などの高レベルプログラムからは隠されているために発生しますmv。 とは異なりmv、rsyncはファイルの変更された部分のみを移動します。
これは、mount --bind バインドマウントとは何ですか?