ファイルシステム総合スレ その20

● 前スレ
ファイルシステム総合スレ その18
https://mao.5ch.net/test/read.cgi/linux/1514472651/l50
ファイルシステム総合スレ その19
https://mao.5ch.net/test/read.cgi/linux/1592027147/

● 関連スレ
ジャーナリングファイルシステム
https://mevius.5ch.net/test/read.cgi/unix/979408065/l50

OpenSolaris/Illumos (OpenIndiana, etc.) 6
https://mevius.5ch.net/test/read.cgi/unix/1337411922/l50

FS関連スレ
https://medaka.5ch.net/test/read.cgi/os/1137387538/l50
過去スレ, 関連リンクは >>2-10 あたりで.

４台で BTRFS RAID 6 にしたけど、一台ハードディスクをふっとばしたら読み出せなくなって困ってる。あんまり、ノウハウでなくてもドキュメント自体がすくないのよね BTRFS って。誰か助けて...

まだバグあるRAID6でトラブルは…

https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

本番運用では使用しないでくださいと書いてあるな
でもまあ基本機能には問題ないはずだから、内容次第じゃ秒で復旧するんじゃないかな？

初心者はext4かxfsにしとけばええか？

xfsで無問題
ext4は今や使ってる人少ないから却って初心者向きじゃない

DebianやUbuntuのデフォルトがext4なのに使ってる人が少ないことないやろ

とりあえずどっちかにしとくは

先月雷で停電しまくったけどそういうのにはxfsは弱いのかな？

そう言う場面に強いのはCoWのbtrfsやzfs

xfsのCoWって安定した？

CoWはブロック層でやれってじっちゃんが言ってた

xfsのCoW使えるぞ、って話あまり聞かないからそう言う事じゃないかな

>>825
メンテナが Red Hat で、その Red Hat が xfs デフォルトなもんだから信用できない。

>>828
停電復旧後のロールバック処理はジャーナリング機能が担うのであって CoW は関係ない。
Linux だと ext2(とfat系) ぐらいだろ、ジャーナリングないのは。

cowでない大抵のファイルシステムはジャーナリングで守られるのはメタデータだけじゃなかったっけ

>>832
ユーザーが多いか少ないかって話だったんだか…

>> 834
確かに上書き途中で停電であれば差は出る場合はあるね。
ただ CoW であっても中途半端なところで書き込みが終わるので停電対策
したいならコミット・ロールバックの概念のあるデータベースに
書き込むしかないな。

>> 835
すまぬ...

>>833
何も知らないなら何も言わないほうが良いぞ
馬鹿がバレるから

基本ジャーナルがやんのはロールバックじゃなくログリプレイ、対象はメタデータ（更新ログじゃなく操作ログを管理する場合はロールバックはあるかもしれない）

DBのトランザクションはリレーションの一貫性保証のための機能で電源断対策に持ち出すのはズレてるかな

電源断対策になるのは操作のアトミック性
create,renameのアプリ側で担保するのが伝統的だけど、ブロック単位で担保してくれんのがcow

電源断対策にcow式ファイルシステムがいるかというと、まともなアプリはcow式前提にしてないし、技術的原理的には電源断に強いかもしれんが効果を発揮するのは限定的だと思ってるわ

どういうこと？
CoWだろうとソフトウェアの対応なんていらんが

>>837
それ流行ってんの？

>>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 とか起動時に復旧するかが表示される。

駄目アプリの Truncate and Write の途中で停電になったら
例え CoW であってもファイルの途中までの書き出し状態で復旧するか
上書きする前に戻されるかだけでしかない。

アプリレベルで意味のあるオートセーブデータとか
アプリレベルで意味のあるアンドゥログがあって初めて停電対策になるのであって
アプリより低層のファイルシステムでは打てる策ではどうあがいても
「効果を発するのは限定的」ですね。

>>842
× リストアが面倒なので
○ ハードリンクの復元が超面倒/思いつかないので

属性を保持したまま内容を一気に入れ替えるのは、今ならcopy_file_rangeがある

で、こいつはCoWファイルシステムじゃないと本当に内容をコピーするので効率が悪い

停電を予測して スナップショットを撮る機能が追加されるとかしないとかいう話は聞いたことがない

そこでNILFSですよ

Nipple?

>>842
renameでのinode置き換えならunlinkはいらんし、user拡張属性なら転記するだけでいいけど何気にしてるか分からん

>>847
10年近く前にそんなファイルシステムを作ってたな
紆余曲折でプロジェクトはポシャったけど

openZFSの新しいDedupについて

https://despairlabs.com/blog/posts/2024-10-27-openzfs-dedup-is-good-dont-use-it/

タイトルからして良いのか使うななのか。言いたい事は何故か分かった

かなり改善されたけど一般的な使い方ではdedupを使う価値は無いとのこと

https://www.phoronix.com/news/Bcachefs-Uncertain-Kernel-Issue

よりによってLinusが行動規範違反持ち出してワロス

Linus先生の精神修養の効果はどれぐらい持続したんだろうか

カーネルは何千人も開発に関わってるプロジェクトだからな
問題があるメンテナは受け入れられないよ

kent君が結構アレなので……

https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13

> ReiserFS Has Been Deleted From The Linux Kernel

ついに……
それにしてもFS開発者ってキチガイ多くね？

>>855
Bcachefs開発者がどんな行動規範違反しているのかかよくわからんのだけど
LKMLでのKentのメール
https://lore.kernel.org/lkml/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk/

> Get your head examined. And get the fuck out of here with this shit.
訳: お前の脳みそ検査しろ。そのクソと一緒にここから出て行いきやがれ

こういう5chみたいな文章がアウトってこと?

zfsはせっかく良いファイルシステムなににちょっと勿体無いね

zfsはエンプラ用途すぎて中小企業や一般ユーザにはとても合わないと思うが

むしろ中小企業向けだろZFSは
でかい企業は分散ファイルシステム使うだろうし

中小企業は
1. 重複排除、スナップショット、圧縮が安定して使え
2. Active Directory の連携し CAL も不要、
3. 故障時ハードベンダーにお任せで社内技術者による属人化を無視可能
な中身がWindows IoT の NAS 製品買うでしょ。

エンタープライズも並列ファイルシステムの Lustre の中身
(ldiskfs(ext4) か ZFS が選択可能) として位ではないかな。
実績面で疑問が残る Lustre ZFS をまともに運用出来る人員を確保
できる組織が存在するかは疑問だが。

zfsよりbtrfsの方が勢いあるしな

NAS企業同士がexfat対btrfsで論争してなかったっけ、どうなったんだろ

ext4の間違いでは？
exfatなんて対抗にならないだろ

あ、素手間違えてたごめん
もちろんext4
思い出そうとして今ぐぐったらQNAP、ReadyNAS、Synologyあたりが論争してたみたい

ext4ファイルシステム破損問題を思い出した
ps://atmarkit.itmedia.co.jp/flinux/rensai/watch2009/watch11a.html

なんでそんな古い記事を
つい2年くらい前にext4が壊れたことあっただろうに
アプデですぐ治ったけど

Synologyは関係ない。
ReadyNASとQNAPが煽り合ってたんだよ。

ReadyNAS
Btrfsの先進性 - ReadyNASが先進的なファイルシステムBtrfsを採用している理由
https://www.netgear.jp/solutions/readynas/readynas_btrfs.html

QNAP
QNAP NASがBtrfsファイルシステムを使用しないのはなぜですか？
https://www.qnap.com/ja-jp/solution/qnap-ext4

QNAP君がBtrfsにグチグチ言ってるのは、こんなFS流行ったら非エンタープライズNASの商売上がったりだからかと思ったら煽り合う相手がいたのかw

対抗馬のBcachefsはまだ実績なさすぎて使い物になるのはいつになる事やら

openzfsがファイル名の1023バイト長に対応した
今までlinuxのまともなfsの中ではgpfsぐらいしか無かったから
windowsとのinteropを気にしてる人にとっては朗報なんじゃ

stdio.h で定義されているからコンパイル済のソフトじゃ使えんじゃん、
て思って調べてみたら結構前(CentOS6/手近にあった最古)でも FILENAME_MAX
は 4096 だったわ。

ビットロット対応のFSふえてくれ
winもmacも含めて

ファイルシステム作る人、圧倒的に性格悪い説
zfs, ReiserFS, Bcachefs

なんで？

>>875
それはフルパスでは？
NAME_MAXがファイル名の規定のはず

ext4の人は性格悪くないから単なる偶然だな
zfsは知らん、reiserfsは妻殺し、bcachefsは手順も踏まず自己主張ばかりうるさい

zfs やOpen Solaris はCDDLで、GPLというかLinuxに成果を取られないようにイジワルしているとしか...

第6回 Debian 会議で Cooper は、Solaris カーネルを書いた技術者らが OpenSolaris が GPL 非互換となるよう要求したと述べている。「Mozilla が選ばれた理由のひとつとして、GPL非互換だからというのがある。

Common Development and Distribution License（CDDL）
ps://ja.m.wikipedia.org/wiki/Common_Development_and_Distribution_License

コピーレフトなのにGPL非互換なライセンスか、こんなのあるんだな

ワイは作者さんの開発成果に世話になってるから感謝してる、性格はしらん

オラクルは邪悪

>>879
NAME_MAXで正しいけどglibcでそれが問題になるような処理ってどこかにある？
現実に問題になるのはPATH_MAXのほうだと思う
実際zfsで500文字ぐらいのファイル作って試してみてるけど今のところ問題ないな

encfsでwinのファイルがコピーできなくて困ったことならある

fedora のインストーラは btrfs を使う時、/boot 以外を一つのbtrfs パーティションとして作成してから、/ と /home をサブボリュームとしてマウントしている。
Debian のインストーラじゃ出来ない気がしている。

Debianだとbtrfsにすると/boot/efiを除く/以下全体がサブボリューム名@rootfsになる
細分化したいときはインストーラ終了後再起動前にライブイメージに居残って操作するといい

ファイルシステムって普通1つのファイルの最大サイズも〇〇バイトまでみたいな制限があると思いますが
tmpfsにも1ファイルあたりの最大サイズとかって決まりみたいなのってありますか？

知らんけど仕様の制限より先にメモリサイズの制限のほうが先に来るだろう

+------------------------------------------+
| A: Btrfs Send/Receive再利用試験 |
| (長期不使用機能、試験欲す) |
| (元snapshot: /timeshift/.../@, @home) |
+------------------------------------------+
|
v
+------------------------------------------+
| B: 現状確認・Snapshot所在確認 |
| (lsblk, mount /dev/sda1, ls) |
| (先ディスクにて発見: |
| /mnt/backup_btrfs/@_snapshot, |
| @home_snapshot) |
+------------------------------------------+
|
v
+------------------------------------------+
| C: 手動復元手順の複雑性再認識 |
| (fstab, grub, initramfs等手作業多) |
| (timeshift自動復元との対比) |
+------------------------------------------+
|
v
+------------------------------------------+
| D: `btrfs subvolume snapshot` の |
| 非破壊性確認 (Copilot助言) |
| (操作自体は安全、然しmount/fstab変更 |
| 伴えば現環境復帰煩雑の可能性) |
+------------------------------------------+
|
v

+-------------------------------------------------+
| E: 🔥迷い・目的の再評価 |
| 🌱「分離故安全か？...だが切替煩雑」 |
| 🌱「最悪時保険？...1.5年前状態に戻す価値薄」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| F: 🎯目的変更・作業範囲縮小 |
| 「今回は旧snapshotよりデータコピーのみに止む」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| G: Copilot追認 |
| (個別データ抽出・現環境維持を善策と評価) |
| (btrfsサブボリューム複製、現環境と分離独立) |
+-------------------------------------------------+
|
v

+-------------------------------------------------+
| H: 過去の最悪事態経験想起 |
| (timeshift --restore不能は稀有) |
| (手動snapshotは最終保険として有効と認識) |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| I: 最終結論・認識 |
| 「苦労して整えし現環境を旧状態へ戻すは非得策」|
| (現環境維持優先、旧データは必要時参照) |
+-------------------------------------------------+

似たようなファイルシステムがゴロゴロあるな
同じような機能同じような目的

プロプラエタリィなNTFSの存在がガンですよ。

btrfs と bcachefs ならどっちを使うべき？

(Linus Torvalds) in August of 2024 that "nobody sane uses bcachefs and expects it to be stable".
ps://en.m.wikipedia.org/wiki/Bcachefs

>>897
草
Kent Overstreet 氏がなんかアレっぽいからやめとくわ

An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11
ps://www.phoronix.com/review/linux-611-filesystems

f2fsすげーな、SDカードいたわりファイルシステムってだけじゃないのか

F2FSはAndroidのストレージのファイルシステムに使われてるから
今はもうかなりのデバイス数で使われてる

おもしろそうな話をしているようなのできました

f2fsってのがあるんか

btrfsの更新履歴を読むと raid5 なら行けそうな気がしてきた。

Raid5はもう使っても大丈夫になってたはず
たしかLinux6.2から
カーネルバージョン低いと注意

RAID5まで使えるようになったらもうBtrfs敵無しでは？

>>904
Debain 12 (Bookworm) 2023年は6.1なのでDebian 13(Trixie)からは大丈夫になるのか。良い情報だ。

stableのカーネルって普通にbackportsのに
更新して使うものだと思ってた…
絶対にミスが許されない鯖とかでない限りは

レスチで悪いが、
Debian Backports に関しては Kernel で問題は出ないだろうけど、Backports でバージョン上げて不具合あっても、本家の解消待ちのイメージしかない。Emacs の事だが。

>>904
なってません
追加機能無しで出来る修正が一つ入ったってだけで
write holeは根本的に解決してないし
多分これからしばらくも解決されません

ttps://www.phoronix.com/news/Linux-6.2-Btrfs-EXT4
ttps://www.reddit.com/r/btrfs/comments/127zmsx/what_do_you_think_about_the_kernel_62_btrfs/

そもそもRAID5実装自体が完全に安全だと仮定しても
何TBのHDDでRAID5とかはリビルド中にUREに遭う確率を考えると割に合わない

Btrfs使ってるけどRAID10で十分だよ

リビルドなんてZFSでもそんな信頼性高いもんじゃないからどうでもいいわ
なんか壊れたら素直に再構築すべき

リビルドによる冗長性に期待しないんだったら
わざわざパリティ付きストライプで分散して書き込む理由なんて一つもない
そして現実的な容量あたりの回復不可能エラーの確率を考えると
6はともかくまともな冗長性が期待出来ないRAID5なんか今は使う理由はまるでない
それこそRAID1どころか多くの場合で破損部分が明白かつ単純で
無事な部分を吸える可能性が高い分だけシングル運用の方が遥かにマシ

リビルドによる冗長性ってなに？

RAIDはアレイが破損したらリビルドかける前に
全データバックアップしろが通説だと思った

バックアップする空きストレージがないとか
そもそもバックアップがないなら
そもそもその運用がおかしい…
(捨ててもいいデータだけとか観て消し録画は除く)

なんでRAIDやりたがるのか意味不明
バックアップの工夫をそれなりにやって
ダウンタイムやデータ損失期間を減らすための最終仕上げだよね
それとも広告であるネット記事を見て導入が大半?

>>913
ttps://e-words.jp/w/%E5%86%97%E9%95%B7%E6%80%A7.html
ttps://www.buffalo.jp/topics/trouble/detail/recovery_0005.html
RAIDの文脈で「冗長性」ってのは
RAID構成内に故障したハードウェアが出てもデータの完全性が損なわれない事
「リビルド」ってのはもっぱらその故障したハードウェアを入れ替えて元の冗長性を持つ構成に再構築することを指す
この説明でわかんないんだったら俺にはうまく説明出来ねえ
「リビルドできる冗長性に～」の方がもっと正確な言い回しだったといえばそれはそうなので
わかってて言ってたら単に俺の日本語が下手でごめんだな

>>914-915
本当にクリティカルなデータを扱うなら
定時記録的なオフラインバックアップが常に別にあって
「退避」や「サルベージ」をやる必要すらほぼ無いのが理想だし本当なら当然
もちろん実現にはハードウェアも運用もコストが相応に要るので難しくなるけどね
冗長性が無い状態での改めての読み出しは
結局リビルドとやってる事は似てて当然ながらもし残りのハードウェアが故障すれば(読み出せなくなった分は)完全にパーなんで
これはどちらかというと現実的な次善策

それこそbtrfsならスナップショットとsend/receiveをうまく使えば
オフラインバックアップ用の場所にも高速に増分バックアップ出来るよ

btrfsのsnapは呆気ないほど簡単にファイルの先祖返りが長期も短期も可能で、
WinがやっているVolume Shadow Copyの上位互換って印象で、個人的にはとても好き。

でも、バックアップは別途必要かなって思っている。神経質なだけかもだけれど、データって一番大事だから増分・差分だけじゃなく、本体も自分は保持するようにしている。

>>916
冗長性ってリビルドのためではなくサービスを止めないためのものでは？
リビルドしなくても冗長性は重要だよ

びっくりしたのはRAIDでリビルド機能が無いと言われたとき
そりゃまぁデータ消えないけどそのまま運用とか狂人だろうに
おーこわいこわい