24/10/06 06:08:31.42 zw6R/dBZ.net
xfsのCoW使えるぞ、って話あまり聞かないからそう言う事じゃないかな
832:login:Penguin
24/10/06 11:41:37.08 SXXTeXeo.net
>>825
メンテナが Red Hat で、その Red Hat が xfs デフォルトなもんだから信用できない。
833:login:Penguin
24/10/06 11:49:09.82 SXXTeXeo.net
>>828
停電復旧後のロールバック処理はジャーナリング機能が担うのであって CoW は関係ない。
Linux だと ext2(とfat系) ぐらいだろ、ジャーナリングないのは。
834:login:Penguin
24/10/06 13:05:00.01 fwRfDtt8.net
cowでない大抵のファイルシステムはジャーナリングで守られるのはメタデータだけじゃなかったっけ
835:login:Penguin
24/10/06 13:18:49.26 3uVRZx0K.net
>>832
ユーザーが多いか少ないかって話だったんだか…
836:login:Penguin
24/10/06 17:29:17.85 SXXTeXeo.net
>> 834
確かに上書き途中で停電であれば差は出る場合はあるね。
ただ CoW であっても中途半端なところで書き込みが終わるので停電対策
したいならコミット・ロールバックの概念のあるデータベースに
書き込むしかないな。
>> 835
すまぬ...
837:login:Penguin
24/10/08 07:25:45.36 6KT/uJBx.net
>>833
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから
838:login:Penguin
24/10/08 17:05:42.28 BFua4mkm.net
基本ジャーナルがやんのはロールバックじゃなくログリプレイ、対象はメタデータ（更新ログじゃなく操作ログを管理する場合はロールバックはあるかもしれない）
DBのトランザクションはリレーションの一貫性保証のための機能で電源断対策に持ち出すのはズレてるかな
電源断対策になるのは操作のアトミック性
create,renameのアプリ側で担保するのが伝統的だけど、ブロック単位で担保してくれんのがcow
839:login:Penguin
24/10/08 18:24:09.03 BFua4mkm.net
電源断対策にcow式ファイルシステムがいるかというと、まともなアプリはcow式前提にしてないし、技術的原理的には電源断に強いかもしれんが効果を発揮するのは限定的だと思ってるわ
840:login:Penguin
24/10/08 23:49:22.20 g4k9TmhA.net
どういうこと？
CoWだろうとソフトウェアの対応なんていらんが
841:login:Penguin
24/10/09 22:58:24.38 TGngPSqW.net
>>837
それ流行ってんの？
842:login:Penguin
24/10/10 23:29:15.63 xeeQIOkG.net
>>840
たぶん「まともなアプリ」は
(1) 上書きせずに同期書き込みで別ファイル作成(Create, Write, Close and Sync)、
(2) 上書き前のファイルを削除、
(3) (1)で作成したファイルをリネーム
する(つまり手間をかける)って話かと。
まともじゃない駄目アプリは (1)-(3) を実行せずに上書き (Truncate and Write)
ですましちゃうから CoW じゃないと処理途中で停電した場合にデータが吹っ飛ぶ
って事じゃないかな。
rename するとファイルの xattr 属性が吹っ飛ぶ/リストアが面倒なので
「まともなアプリ」でも実際には (2),(3) は実行せず、
(2a) オリジナルファイルを上書き (Truncate and Write) だな。
途中で停電になった場合は次回アプリ起動時に修復するかをユーザに問い合わせる。
例えば Linux の vi とか Windows の MS-Word とか起動時に復旧するかが表示される。
843:login:Penguin
24/10/10 23:42:22.27 xeeQIOkG.net
駄目アプリの Truncate and Write の途中で停電になったら
例え CoW であってもファイルの途中までの書き出し状態で復旧するか
上書きする前に戻されるかだけでしかない。
アプリレベルで意味のあるオートセーブデータとか
アプリレベルで意味のあるアンドゥログがあって初めて停電対策になるのであって
アプリより低層のファイルシステムでは打てる策ではどうあがいても
「効果を発するのは限定的」ですね。
844:login:Penguin
24/10/10 23:52:24.30 xeeQIOkG.net
>>842
× リストアが面倒なので
○ ハードリンクの復元が超面倒/思いつかないので
845:login:Penguin
24/10/10 23:56:09.82 WGFMDZfJ.net
属性を保持したまま内容を一気に入れ替えるのは、今ならcopy_file_rangeがある
846:login:Penguin
24/10/10 23:57:11.07 WGFMDZfJ.net
で、こいつはCoWファイルシステムじゃないと本当に内容をコピーするので効率が悪い
847:login:Penguin
24/10/11 07:39:44.04 /6otHtpl.net
停電を予測して スナップショットを撮る機能が追加されるとかしないとかいう話は聞いたことがない
848:login:Penguin
24/10/11 14:12:45.09 mj4qPltc.net
そこでNILFSですよ
849:login:Penguin
24/10/11 16:05:09.61 P6k6G+uZ.net
Nipple?
850:login:Penguin
24/10/11 22:21:34.48 5hgxSCWq.net
>>842
renameでのinode置き換えならunlinkはいらんし、user拡張属性なら転記するだけでいいけど何気にしてるか分からん
851:login:Penguin
24/10/12 00:50:45.17 oiiqPhbz.net
>>847
10年近く前にそんなファイルシステムを作ってたな
紆余曲折でプロジェクトはポシャったけど