知らなかった。reflinkは明示的に使う機能だと思っていたので、デフォで有効になっていることが驚きです。これほど影響範囲の広いパッケージで、デフォ挙動の変更を行うにあたってどのような議論があったのでしょうか
どうせfs依存だろと思った
大きなデータに対する障害体制は弱くなってしまうし、小さいデータはこんなことをして容量を節約する意味もないので、正直やめてほしい。
裏でCoWが勝手に走ってたの、言われなきゃ一瞬でコピー完了して速いな〜で済ませてた
https://www.tohoho-web.com/linux/cmd/cp.html#special-features --reflinkオプションの解説を読めば分かるけどreflinkはCopy on Write(変更される時点でコピーが作成される)なので当然と言えば当然の挙動
copy on writeとのこと。ファイル全体でなく、部分的にも管理してくれるのね//バックアップ用途なら別ストレージ使えば、この機能は使われないよね
macにもCoWのコピーがあるけど、あっちは-cオプションを渡さないと有効にならないんだよな
物理故障（ビット化けなど）への耐性のために同じFS内でcpするなんてありえないので、CoW大歓迎よ。
えっ？！sync;sync;sync;reboot ってしないとだめなのか？
ZFS勢には2005年くらいから既知だし、APFS(2017年)からも普通に使われている（WWDCでも高速ファイルコピーのデモがあった）。Arch Linuxユーザーはbtrfs利用が多いのでLinux勢にも既知かと思ってたよ
"never: 必ずデータコピーする。 " えっなにそれこわい。業務でxfs 使うが知らなかった…
それ cp コマンドじゃなくて、ファイルシステムの仕様じゃないの…と思って読み始めたら、そう書いてあった。
これはファイルシステム上の話だが、そもそもファイルシステムより低いレイヤの物理ストレージでも似たような状況になっている。スナップショット機能を実現するためであったり、いろんな要因がある。
btrfsを勉強したときにbtrfsなどが使っていることを知りました。本当に違いが出たら書き込む。素晴らしいですね。たぶんスナップショットが一瞬なのもそれだったような(?)
“別ファイルで同じデータを共有できるreflink使えるファイルシステムはLinuxではXFS,Btrfs。GNU cp（2021以降）はreflinkを使えたら使う。ext4なら遅いがXFSなら一瞬。同ディスク内のコピーがバックアップにならない問題も”
zfsあたりの話じゃないの？って思ったら似たような話だった
しゃろう？
"reflnkが使えたら使う" っていうcpの仕様(デフォルト挙動の選択)やろがい
コピーオンライトとか対応してるファイルシステムならコピーしないで書き込み時にコピーするよね
“cpはreflinkを使えたら使うというモードになっています。つまり、XFSやBtrfsでcp <src> <dest>を実行すると<src>と<dest>はコマンド実行直後はファイルコンテンツをディスク上で全て共有するようになり”
AIで並列に開発する時に、git管理外のファイルも難しいことせずに単にworktreeへCoWで持ち込めばいいよねってのに繋がる
同一ドライブでコピーしてる時点で、障害体制もクソもないから参照で済ます方が賢いだろ
早いし不整合も起きないしフラグで選択できるしよく出来た仕組みだな～（こなみ
ファイルシステムのことやろなと読み始めたらやっぱりか。
ext4がそうじゃないっぽいことの方が意外だった。
デフォルトでreflink出来ればするようになってたのは知らなかった
sync;sync;sync;とオマジナイ唱えてshutdownみたい
これ、ファイルシステムによっては、仮想機のスナップショットでバックアップ取ったときひょっとする？！
`cp`はディスク上ではデータをコピーしないことがある
知らなかった。reflinkは明示的に使う機能だと思っていたので、デフォで有効になっていることが驚きです。これほど影響範囲の広いパッケージで、デフォ挙動の変更を行うにあたってどのような議論があったのでしょうか
どうせfs依存だろと思った
大きなデータに対する障害体制は弱くなってしまうし、小さいデータはこんなことをして容量を節約する意味もないので、正直やめてほしい。
裏でCoWが勝手に走ってたの、言われなきゃ一瞬でコピー完了して速いな〜で済ませてた
https://www.tohoho-web.com/linux/cmd/cp.html#special-features --reflinkオプションの解説を読めば分かるけどreflinkはCopy on Write(変更される時点でコピーが作成される)なので当然と言えば当然の挙動
copy on writeとのこと。ファイル全体でなく、部分的にも管理してくれるのね//バックアップ用途なら別ストレージ使えば、この機能は使われないよね
macにもCoWのコピーがあるけど、あっちは-cオプションを渡さないと有効にならないんだよな
物理故障（ビット化けなど）への耐性のために同じFS内でcpするなんてありえないので、CoW大歓迎よ。
えっ？！sync;sync;sync;reboot ってしないとだめなのか？
ZFS勢には2005年くらいから既知だし、APFS(2017年)からも普通に使われている（WWDCでも高速ファイルコピーのデモがあった）。Arch Linuxユーザーはbtrfs利用が多いのでLinux勢にも既知かと思ってたよ
"never: 必ずデータコピーする。 " えっなにそれこわい。業務でxfs 使うが知らなかった…
それ cp コマンドじゃなくて、ファイルシステムの仕様じゃないの…と思って読み始めたら、そう書いてあった。
これはファイルシステム上の話だが、そもそもファイルシステムより低いレイヤの物理ストレージでも似たような状況になっている。スナップショット機能を実現するためであったり、いろんな要因がある。
btrfsを勉強したときにbtrfsなどが使っていることを知りました。本当に違いが出たら書き込む。素晴らしいですね。たぶんスナップショットが一瞬なのもそれだったような(?)
“別ファイルで同じデータを共有できるreflink使えるファイルシステムはLinuxではXFS,Btrfs。GNU cp（2021以降）はreflinkを使えたら使う。ext4なら遅いがXFSなら一瞬。同ディスク内のコピーがバックアップにならない問題も”
zfsあたりの話じゃないの？って思ったら似たような話だった
しゃろう？
"reflnkが使えたら使う" っていうcpの仕様(デフォルト挙動の選択)やろがい
コピーオンライトとか対応してるファイルシステムならコピーしないで書き込み時にコピーするよね
“cpはreflinkを使えたら使うというモードになっています。つまり、XFSやBtrfsでcp <src> <dest>を実行すると<src>と<dest>はコマンド実行直後はファイルコンテンツをディスク上で全て共有するようになり”
AIで並列に開発する時に、git管理外のファイルも難しいことせずに単にworktreeへCoWで持ち込めばいいよねってのに繋がる
同一ドライブでコピーしてる時点で、障害体制もクソもないから参照で済ます方が賢いだろ
早いし不整合も起きないしフラグで選択できるしよく出来た仕組みだな～（こなみ
ファイルシステムのことやろなと読み始めたらやっぱりか。
ext4がそうじゃないっぽいことの方が意外だった。
デフォルトでreflink出来ればするようになってたのは知らなかった
sync;sync;sync;とオマジナイ唱えてshutdownみたい
これ、ファイルシステムによっては、仮想機のスナップショットでバックアップ取ったときひょっとする？！