[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
820: 2024/09/25(水)04:22 ID:UHAArs8N(1) AAS
４台で BTRFS RAID 6 にしたけど、一台ハードディスクをふっとばしたら読み出せなくなって困ってる。あんまり、ノウハウでなくてもドキュメント自体がすくないのよね BTRFS って。誰か助けて...
821: 2024/09/25(水)16:34 ID:B90ftVDC(1) AAS
まだバグあるRAID6でトラブルは…
822: 2024/09/25(水)18:09 ID:OctKMZ6U(1) AAS
外部ﾘﾝｸ[html]:btrfs.readthedocs.io
本番運用では使用しないでくださいと書いてあるな
でもまあ基本機能には問題ないはずだから、内容次第じゃ秒で復旧するんじゃないかな？
823: 2024/10/05(土)12:37 ID:0Mg6G2gj(1) AAS
初心者はext4かxfsにしとけばええか？
824: 2024/10/05(土)12:42 ID:n9lFPbzQ(1) AAS
xfsで無問題
ext4は今や使ってる人少ないから却って初心者向きじゃない
825(1): 2024/10/05(土)15:20 ID:0h7rk2nA(1) AAS
DebianやUbuntuのデフォルトがext4なのに使ってる人が少ないことないやろ
826: 2024/10/05(土)15:34 ID:TCuh3FMI(1) AAS
とりあえずどっちかにしとくは
827: 2024/10/05(土)19:59 ID:wkYv90CH(1) AAS
先月雷で停電しまくったけどそういうのにはxfsは弱いのかな？
828(1): 2024/10/05(土)20:07 ID:kq62xYz3(1) AAS
そう言う場面に強いのはCoWのbtrfsやzfs
829: 2024/10/05(土)20:10 ID:HzaabSfC(1) AAS
xfsのCoWって安定した？
830: 2024/10/05(土)22:23 ID:VwtDKolW(1) AAS
CoWはブロック層でやれってじっちゃんが言ってた
831: 2024/10/06(日)06:08 ID:zw6R/dBZ(1) AAS
xfsのCoW使えるぞ、って話あまり聞かないからそう言う事じゃないかな
832(1): 2024/10/06(日)11:41 ID:SXXTeXeo(1/3) AAS
>>825
メンテナが Red Hat で、その Red Hat が xfs デフォルトなもんだから信用できない。
833(1): 2024/10/06(日)11:49 ID:SXXTeXeo(2/3) AAS
>>828
停電復旧後のロールバック処理はジャーナリング機能が担うのであって CoW は関係ない。
Linux だと ext2(とfat系) ぐらいだろ、ジャーナリングないのは。
834: 2024/10/06(日)13:05 ID:fwRfDtt8(1) AAS
cowでない大抵のファイルシステムはジャーナリングで守られるのはメタデータだけじゃなかったっけ
835: 2024/10/06(日)13:18 ID:3uVRZx0K(1) AAS
>>832
ユーザーが多いか少ないかって話だったんだか…
836: 2024/10/06(日)17:29 ID:SXXTeXeo(3/3) AAS
>> 834
確かに上書き途中で停電であれば差は出る場合はあるね。
ただ CoW であっても中途半端なところで書き込みが終わるので停電対策
したいならコミット・ロールバックの概念のあるデータベースに
書き込むしかないな。
>> 835
すまぬ...
837(1): 2024/10/08(火)07:25 ID:6KT/uJBx(1) AAS
>>833
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから
838: 2024/10/08(火)17:05 ID:BFua4mkm(1/2) AAS
基本ジャーナルがやんのはロールバックじゃなくログリプレイ、対象はメタデータ（更新ログじゃなく操作ログを管理する場合はロールバックはあるかもしれない）
DBのトランザクションはリレーションの一貫性保証のための機能で電源断対策に持ち出すのはズレてるかな
電源断対策になるのは操作のアトミック性
create,renameのアプリ側で担保するのが伝統的だけど、ブロック単位で担保してくれんのがcow
839: 2024/10/08(火)18:24 ID:BFua4mkm(2/2) AAS
電源断対策にcow式ファイルシステムがいるかというと、まともなアプリはcow式前提にしてないし、技術的原理的には電源断に強いかもしれんが効果を発揮するのは限定的だと思ってるわ
840(1): 2024/10/08(火)23:49 ID:g4k9TmhA(1) AAS
どういうこと？
CoWだろうとソフトウェアの対応なんていらんが
841: 2024/10/09(水)22:58 ID:TGngPSqW(1) AAS
>>837
それ流行ってんの？
842(2): 2024/10/10(木)23:29 ID:xeeQIOkG(1/3) AAS
>>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: 2024/10/10(木)23:42 ID:xeeQIOkG(2/3) AAS
駄目アプリの Truncate and Write の途中で停電になったら
例え CoW であってもファイルの途中までの書き出し状態で復旧するか
上書きする前に戻されるかだけでしかない。
アプリレベルで意味のあるオートセーブデータとか
アプリレベルで意味のあるアンドゥログがあって初めて停電対策になるのであって
アプリより低層のファイルシステムでは打てる策ではどうあがいても
「効果を発するのは限定的」ですね。
844: 2024/10/10(木)23:52 ID:xeeQIOkG(3/3) AAS
>>842
× リストアが面倒なので
○ ハードリンクの復元が超面倒/思いつかないので
845: 2024/10/10(木)23:56 ID:WGFMDZfJ(1/2) AAS
属性を保持したまま内容を一気に入れ替えるのは、今ならcopy_file_rangeがある
846: 2024/10/10(木)23:57 ID:WGFMDZfJ(2/2) AAS
で、こいつはCoWファイルシステムじゃないと本当に内容をコピーするので効率が悪い
847(1): 2024/10/11(金)07:39 ID:/6otHtpl(1) AAS
停電を予測して スナップショットを撮る機能が追加されるとかしないとかいう話は聞いたことがない
848: 2024/10/11(金)14:12 ID:mj4qPltc(1) AAS
そこでNILFSですよ
849: 2024/10/11(金)16:05 ID:P6k6G+uZ(1) AAS
Nipple?
上下前次1-新書関写板覧索設栞歴
あと 153 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.014s