ファイルシステム総合スレ その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 あたりで.

国会議員が詐欺師の常套句です

>>310
部屋に大きな展開のきっかけになるんだろうね
https://i.imgur.com/izAemlf.jpeg
https://i.imgur.com/LsCeMJd.jpeg

あぼーん

>>804
早速やってみる

https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets

> Linus Torvalds Begins Expressing Regrets Merging Bcachefs

BcachefsもReiserfsと同じ運命をたどりそうｗ

Linuxは大量の人数で作り上げているものだと理解しないとな
個人開発みたいに作ったコードをぽんぽん送ってもやべーやつになる

たまには、1000行プルリクエストする人がいても、まあ良いんじゃね。
どっちの気持ちも分かるじゃない。

あぼーん

>>809
遅いわもう完走済み

ZFSのRAIDZ2でファイルシステム組んでるんだけど、カーネルパニックになって中身が読み取れなくなった。

頭ハゲそう。。。

ま、バックアップからリストアがんばれ

www.phoronix.com/news/Bcachefs-For-Linux-6.12

> Bcachefs Hopes To Remove "EXPERIMENTAL" Flag In The Next Year

夢が広がりんぐ（死語）

> Kent reports that for multi-threaded creates that Bcachefs is said to be 3~4x faster than XFS.

すごいじゃん

bcachefsは今のところ採用してる企業を一つも見ないのがね
個人用途のおもちゃでしかない

> The end-user experience is still pretty painful when the root filesystem needs a fsck

まだかなりの人柱モードだよな

何処かの企業がサポートしているのかは気になる。
今生き残っているのはRH/IBM/Oracleの支援があるか、SGI/Sun 他の遺産だし。

zfsは権利問題で扱い辛くてbcachefs出たばかりだからガチでは使えんし
Raid5/6問題解決したらBtrfsで十分ってなりそう

20年前ならインテリジェンスのあるファイルシステムは需要あったんだろうけど、今更感強いしな

最近はオブジェクトストレージが使われることも多いからなあ

４台で 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のストレージのファイルシステムに使われてるから
今はもうかなりのデバイス数で使われてる