回答:
堅牢性の理由から、データの破損から保護するためにコピーを作成する必要があるため、これはデフォルトではありません。また、パフォーマンス上の理由から、レイテンシーに敏感なプロセスがCoWファイルで動作し、おそらくメカニカルディスクの別の部分への書き込みによって遅延するのではなく、コピー時に書き込みを行うことができます。上記の制約がないため、coreutils v8.24 mvからデフォルトでreflinkされることに注意してください。
それは多分そう、それは他のコピーユーティリティ（と同じように動作していること、デフォルトではない理由を知ってはいけないrsync、cpio、pax、tarそれはサポートしていない（またはファイルがあることを許可しないインターフェースを介してコピーされたときに...） （NFS、Samba、Fuse File Systems Layerなど）。
私は数年前と同じ状況にあり、GNU cpコードをすばやく見て、それでも同じです。異なるデフォルトの動作を得るためにコードを修正する必要があります：
--- coreutils-8.21/src/cp.c~ 2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c 2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
x->interactive = I_UNSPECIFIED;
x->move_mode = false;
x->one_file_system = false;
- x->reflink_mode = REFLINK_NEVER;
+ x->reflink_mode = REFLINK_AUTO;
x->preserve_ownership = false;
x->preserve_links = false;
大きな問題の1つは、書き込み時にコピーを実行するためのスペースが不足する可能性です。
通常のコピーでは、コピーが完了するとすぐに、ファイルの既存の部分への書き込みが失敗することを心配する必要はありません。スペースが完全に割り当てられ、ファイルを削除するまで消えません。しかし、reflinkコピーでは、コピーを作成するのに十分なスペースがなかったため、数週間または数か月後に、ファイルの既存の部分への書き込みが失敗するリスクが常にあります。
そのような操作が失敗したときに、システムがあなたの背中の後ろでreflinkコピーを行っていたことを発見することは、かなり厄介な驚きです。
alias cp='cp --reflink=auto --sparse=always'
コードをパッチするよりも理にかなっています
/bin/cp、同様のシェルスクリプトに置き換える
データの「損失」から保護するためにコピーを実行することが必要な堅牢性の理由。
それが理由だとは知りませんが、起こりうる悪いことはメディアの破壊に限られています。ほとんどすべてのブロックデバイスには、前方誤り訂正（パリティ）でない場合、何らかの形の破損識別（crc）があります。
パフォーマンス上の理由ではありません。
CoWは、消去の一部のみが発生したときに発生しますか？ブロックが書き込まれます。最新の！disk！デバイスのハードウェアブロックサイズは4kの倍数です。4kの一部を変更すると、ドライブは4k全体を読み取って再度書き込みますが、その上、カーネルは同じことを行うため、ブロックデバイス、SSDなどに到達する部分的な書き込みはありません。 。カーネルは同じ理由でCoWを実行する必要があります。キャッシュされたコピーがない限り、デバイスの他の部分に存在するデータを作成することはできません。論争。ただし、ファイルのコピーをキャッシュすることとファイルをコピーすることは操作が異なるため、前者の方がはるかに安価です。
書き込みのアドレスは重要ではありませんが、「デバイスの一部の未使用部分」は、「ファイルのブロックが現在存在する場所」よりも安く発見できることを知っておいてください。
実際、CoWの方法は、単にブロックデバイスを更新するよりも安価であるか、同等です。ブロックデバイスについて話していないのなら、それはまた別の話になるでしょう...どこかにテープで書かれています。