一部のファイルシステム（特にXFSとbtrfs）は、ファイルブロックレベルでの書き込み中のコピーをサポートしています。これは、ファイルが変更されるまでファイル間で共有される基本ブロックを再接続することによって行われます。
ディレクトリは本質的にinodeの連想配列マッピングファイル名ディレクトリと同様の作業を行うのは簡単なはずです。
Linux（または他のUnixシリーズシステム）でこの機能をサポートできるファイルシステムが開発されましたか？
おそらく、relinkを使用するのと同じように、カーネルサポートが必要になるでしょう。このような呼び出しです。ファイル範囲のコピー( ) はディレクトリに適用されます。
この作業を積極的に行う人はいますか？まだ誰もやりたくないからですか、それともこれが悪い考えなのか不要な理由がありますか？
克服すべき具体的な技術的障害物はありますか？
また、見ることができますhttps://serverfault.com/questions/129969/is-there-a-way-to-create-a-copy-on-write-copy-of-a-directory これは実際に質問に答えません。
ベストアンサー1
克服すべき具体的な技術的障害物はありますか？
一つの障害は意味論的な違いです。ディレクトリをコピーすると（ターゲットがまだ存在しない場合）、すべてのコンテンツのコピーだけでなく、すべてのコンテンツを指す新しいディレクトリも作成されます。具体的には、ソースとターゲットのディレクトリが最終的に同じ名前を含んでいても、各名前のターゲット inode が異なることを意味します。
ファイルを複製するのと同じ方法でディレクトリを複製すると、同じ内容の inode を指す 2 つのディレクトリが作成されます。実際、ソースディレクトリの内容へのハードリンクを含むディレクトリが作成されます。これはディレクトリでは機能せず、ファイルの素晴らしい意味を生成します。 asをdira含むレプリカは編集も編集するという意味fileですが、これは元の意図ではないかもしれません。dirbdirb/filedira/file
したがって、これは、ディレクトリコピーの共有ストレージが通常は機能しないことを意味し、場合によっては便利です。
copy_file_rangeそしてFICLONE ioctlSただし、プライマリストレージが共有されると仮定しないでください。 「カーネル、このファイルの一部をコピーしてください」形式の要求です。ストレージを共有でき、委任コピーが読み取りおよび書き込みよりも効率的であるという利点があります。たとえば、ネットワークファイルシステムはサーバー上のレプリケーションを処理できます。これはクライアントベースのコピーよりもはるかに効率的です。デフォルトのリポジトリを共有しなくても、ディレクトリコピーにこの推論を適用すると便利です。
有用なシナリオでも、カーネル操作は実装して使用するのが複雑になる可能性があります。
ファイル複製操作を実行するには、最初に単一のファイルシステムにある単一のファイルを処理する必要があります。それにもかかわらず、複数のファイルシステムにわたってレプリカを処理する規模が拡大copy_file_rangeするにつれていくつかの問題。
ディレクトリの「複製」操作ははるかに複雑です。ディレクトリのコピーには、ディレクトリ自体をコピーする以外の操作が含まれます（つまりファイル名を inode にマッピング) とディレクトリの内容.すでに述べたように、ファイルをハードリンクすることはできません。これが許容可能な単純化であっても、複製したいディレクトリ内のディレクトリなど、ハードリンクできない項目を処理する必要があります。その後、マウントポイントが作成され、「面白い」レベルが大幅に増加しました。もちろん、これらすべては権限を扱うときに発生します。
誰かがこれらすべてを実装していると仮定すると、既存のコードをフォールバックとして使用して、新しいタスクを使用するように関連するユーザースペースプログラムを更新する必要があります。単一ファイルの複製とは異なり、セマンティクスはかなり異なり、すべての場合に新しい機能を組み合わせることは容易ではないかもしれません。結果ファイルシステムの意味も異なります（おそらく価値がある場合は、世界を崩さずに変更できます。relatimeおよび参照noatime）。
まだ考えていない他の障害物があるかもしれませんが、最初の障害物はディレクトリが実際にリポジトリを共有する可能性がほとんどないことを示しています。