「cp -R --reflink = always」がbtrfsファイルシステムで標準コピーを実行するのはなぜですか?


12

Btrfsはコピーオンライトをサポートしています。私はその機能を使用してディレクトリを複製しようとしました:

cp -R --reflink=always foo_directory foo_directory.mirror

コマンドはほぼ瞬時に(のようにbtrfs subvolume snapshot)完了すると予想していましたが、cpコマンドは低速で標準的なコピーを実行しているようです。

マニュアルページによると、私は--reflink=alwaysコピーオンライトを実施することを期待していました:

--reflink [= always]が指定されている場合、軽量コピーを実行します。データブロックは変更された場合にのみコピーされます。これが不可能な場合、コピーは失敗するか、または--reflink = autoが指定されている場合は、標準のコピーにフォールバックします。

質問:

  • なぜ--reflink=always動かないのか知っていますか?
  • 代わりにどのオプション(または他のコマンド)を使用すればよいですか?

回答:


20

cp --reflink=alwaysほぼ間違いなく正しく動作しています。そうでない場合、エラーが発生します。設計によって、それが違いだ--reflink=always--reflink=auto。エラーは次のようになります。

# Filesystem that does not support the feature at all
cp: failed to clone `xx' from `yy': Inappropriate ioctl for device

# Filesystem that does support it, but copy across filesystems
cp: failed to clone `xx' from `yy': Invalid cross-device link

小さなファイルがたくさんあるディレクトリ構造をコピーしていますか?その場合cpでも、すべてのディレクトリを作成し、すべてのファイルを開いて閉じる必要があるため、とは異なり、まだ時間がかかりbtrfs subvolume snapshotます。これはおそらく、操作の実行にかかる時間を説明しています。


3
はい、そこには膨大な数のファイルが含まれており、そのほとんどが小さなテキストファイルです。cpがすべてのファイルを処理する必要があることを知りませんでした。ありがとう、それは私には理解できなかった部分でした。私のユースケースでは、書き込み可能なスナップショットを作成する方が良いと思います。
PhilippClaßen、2015

1
ええ、あなたがスナップショットを作成できるなら、それのために行きます。サブボリュームの一部ではなくサブボリュームのみを操作するcp --reflink=alwaysため、クローンを作成しようとしているものがサブボリュームのルートではない場合でも、便利ですbtrfs subvolume snapshot
Celada
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.