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

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

● 関連スレ
ジャーナリングファイルシステム
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はカーネル上げてもいいけど戻すのはリスキーだから
公式で新しいカーネルを提供しているディストリのほうがいいよ

最近バニラカーネル触ってないから知らんけど、BuildPreReq情報は同梱ドキュメントに必ず書かれてたぜ
外す理由がないから、今もあるはず

>>792
aptならholdしておけば良い

sudo dnf exclude <パッケージ名>
でどうにか出来るみたい
arch系は知らん

btrfsの話ならディスク上の基本フォーマットは長らく変わってないし
カーネルバージョン間での非互換機能はあるけどそれも使うと個別に非互換検出ビットが立つから
古いボリューム相手でも(後から操作できる物なら)新機能は問題なく使えるし
もし新しいカーネルのみの機能を持つボリューム相手に
古いカーネルでマウントしようとしてもroのみあるいはマウント不可になるので安全

実際にzstd圧縮やspace_cache=v2が入る以前の4.4(ルーター)と6.3(PC)の間で
compress=lzo,space_cache=v1で双方にマウントしたり戻したりしてるけど何の問題もないよ

最近のTwitterで顕著だけど故意にフェイクニュース流してる奴結構いるよな
『騙されてやんの～』という◯ナ二―の一種なんかね

あとはオンボロSSDやSDカードでssdオプション有効にすると動作怪しくなるのと
ライトホール問題絡んでくるRAIDが怖いがそれらの点以外は便利なんだよなbtrfs
VMゲストしたときの性能についてはあきらめてLVM等使うかvirtiofsの今後に期待するって話で落ち着きそうだし

でもサブボリューム単位で透過圧縮やCoWの有無切り替えられないのは誰か何とかしてほしい
（ボリューム分けるって方法もあるが単一ボリュームで気軽にマルチデバイスできるのが本来の強みなのだし）

www.phoronix.com/news/XFS-Maintainer-Steps-Down

> XFS File-System Maintainer Stepping Down

XFSのメンテナが辞任

> Nowadays, people working on XFS seem to spend most of their time
> on distro kernel backports and dealing with AI-generated corner
> case bug reports that aren't user reports. Reviewing has become a
> nightmare...

AI生成のバグレポに延々対処する仕事か
まさに悪夢

疲れただけにも読めるけどAIが悪い？

AIがバグレポって何だろね
有意義なレポートじゃないなら選別AIで対抗だ

ランダムに変な負荷かけたり
1秒間に1000回マウントとアンマウントを繰り返したりするんだろう多分
時代はBtrfsなのにやってられんよな

スタックトレースで分類したら実質数個じゃないのかね

ファジングテストの事でしょ…と思ったが多少違うっぽいな
AIが生成しまくるコーナーケースのバグレポートに疲弊したって話っぽい
まぁXFSは赤帽の生命線なんだから問題起きても赤帽がなんとかしてくれるんじゃない？

修正パッチもAI生成出来るようになるまであと一歩

>>803
なんかJFSがいいよ、っという神の声が聞こえた気がした。
ext4 と比較して利点も欠点もないはずたが、Linux での採用例が少ないという大きな欠点。

ext4でいいがな

>>805
Linux Developers Eye Orphaning The JFS File-System

www.phoronix.com/news/Linux-Possible-Orphan-JFS

もう使ってる人いないしJFS捨てようみたいな話が出てる

マイナーなファイルシステムってマトモにメンテされてないし不具合あっても報告されないし使わないほうがいいよ

AIX, OS/2 では動いていて30年前はいいもの感もあったはず...

RHELで採用されてないということはメンテされていないということに等しい

FacebookってCentOSで動いてるらしいけどファイルシステムはbtrfsなんだよな

ext4もオワコンなのTT

>>810
そう考えるとRHは凄いんだな、と思いました。

Btrfsは事実上facebookがメンテしてるからね
自社でメンテしてるファイルシステムだから採用しやすい

>>812
オワコンというよりいい具合に枯れきった
ファイルシステムになった感じ
先進性より安定性が必要な用途でお呼びがかかる
老兵っぽいイメージ

SUSEもbtrfs使ってるぞ

もちろん頼もしいのが第一だが、
逆に言えば現メタ（だけじゃないが）の使用してるユースケースに沿わない使い方に関しては中々進歩しないのが弱点だと思う
RAID56が長い間ダメダメだったのやFS単品での暗号化や階層キャッシュが望めないのもDCでbtrfs使ってる処がそういう機能に興味もってないからだろうし

RAID5/6 でのバグは直ったのか？
家庭用では無い構成だから関係ないと思ってはいたけど。

治るもクソも根本的なライトホール問題があって、ディスク追加の扱いが悪い意味で柔軟なBtrfsは対処が難しいからメンテ側が乗り気じゃないって話じゃないかな
現状は最新カーネルかつメタデータのraid構成を別にすれば良いけど実績も脳死で使える安心感も皆無だし

とはいえ主流のハードウェアraidはデータ化けに弱いんだからチェックサム有りfsで安心して使えるraidがもっと一般化してほしいお気持ちもある

Btrfsのディスク構成の緩さは異常。なんでもかんでもストレージプールに合体できる

自分はbtrfs嫌いじゃないから不満はないがSSD最適化とか将来的なZonedStorage対応考えるとほかに選択肢なくなっていきそうなのは真剣にどうかと思う

ストレージプール使うと遅くならない？
5400rpm のHDDが悪いのかもしれんし、比較で測定もしてないけど。

bcachefs

HAMMERって広まらないな。

bcachefsの作者を毎月支援してたんだけど、Btrfsがすっかり良くなって支援止めちゃった

OSSって上位互換が登場すると一瞬で廃れるから辛いよね
VSCodeが登場してエディタ系が全滅しちゃったような事がいつでも起こり得る
有料製品みたいに価格で対抗することもできないし

bcachefsは機能的にはBtrfsと差別化できてると思うが
これからメインライン入りしてガンガン開発者集めて安定させないといけないのにlinux6.5マージ失敗のMLのレスバからして雲行き怪しいからどうなるやら

プロプラに言うのはアホだと分かってはいるが
それでもGPFSがフリーで使えたらなあって思う
あれクラスタリングがメインだから勘違いしてる人多いけど
CephやRustreと違ってローカル使いにも適してると思うんだよなあ
使ってるZFS全部捨ててGPFSに乗り換えたいと思うぐらいには

juicefsとか使ってみたら
現代技術の分散ファイルシステムって感じだ

GlusterFS面白いな。
簡単な手順で組める。
我が家のはストライピング構成だから怖いけどw

特殊なRAIDを組まない限りは全部Btrfsで成立する時代になった

Redhatがまたbtrfsに戻ってくるってある？

Fedoraでbtrfs使ってるしRHEL10のデフォルトに採用しても驚かない

顧客の要望があれば導入するでしょ
RHELにとっての一番の顧客ってどこなのか知らんが

RHELも将来的にはcow/cor対応のFS導入するだろうけど
自前の製品群がXFSに特化してそうだから簡単には変えられないだろうしまずはGPLの取り扱いの件何とかすべきだろうなあ

今の Red Hat は Spectrum Scale (GPFS) 販売している IBM が上にいるから
フリーのファイルシステムに積極的には投資はしないでしょ。
メンテに金のかかる多機能なFSじゃなくてXFSを細々とメンテするだけじゃないかな。

IBMがJFS押し付けてきたりして

Btrfsはパフォーマンスがちょっとね。
現状BtrfsはZFSにもボロ負けだからな。
Linux6.5でどの程度改善されるか。
あと、暗号化機能がずっと先送りされたまま。

暗号化は導入するだけでなく高度なセキュリティ検証が必要だからハードルは高いよ
ZFSの暗号化は第三者機関でセキュリティ検証してるのかな

GFS入れたけど遅いw
設定は簡単だからVM置き場ではなく普通のストレージにしたよ。
やっぱ専用機が一番だな。

一口に暗号化っつーてもh/w込みなのかデバイス単位なのかボリューム単位なのかで勝手違うからこういうのは特定の製品持ってる企業がガンガン進めないときついところある
しかし今時ノートpcみたいな要件だと流石に外せない要素になりつつあるからぼくのかんがえたさいきょうのソリューションが欲しいんだよ

暗号化LVM使えば暗号化自体は可能だし
セキュリティ関係で厳密なテストが必要な重い作業の割には
新規に何かを実現できるわけでもないから優先順位は低いでしょう

一度導入したら最後、脆弱性がでるたびに最優先で修正が必要になるし

ZFS mirror、SATAケーブルの差し込み不良でエラー出たけどちゃんと一基で動作して再起動も無停止。
ケーブル直したら変更分だけresilverしてすぐ復旧。今更だけど感動。

ReiserFS Officially Declared "Obsolete"

www.phoronix.com/news/ReiserFS-Obsolete

R.I.P.

再インストールの機会があったのでここ見てcompress-force=zstd:1にしてみた
だいたい良好だけども、m属性やproperty set compression noneも無視して圧縮するかどうかはzstdの判断のみなんだな

bcachefsメインライン入り諦めたっぽい？
作者も開発リソース不足や取り巻きの礼賛で冷静さ失ってそうだし、10年とは言わず数年後くらいに平穏な形で再チャレンジ出来るといいなぁ

TPM-backed Full Disk Encryption is coming to Ubuntu

https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu

UbuntuがWindowsのbitlockerみたいなTPM使ったディスク暗号化やるみたい

TPMはプロ相手にはセキュリティ上の追加効果は殆どないのに
一般のユーザーはデータを救出不可能になるリスクが増すというデメリットばかりの代物だぞ

パフォーマンスの問題が解決するんとちゃうの？ソフト暗号複合が遅いから暗号化しないユーザーたち

この場合はパスワード入力不要でTPMだけでディスク暗号化する機能が追加されるという話のようだ。
外部から自分でデータを救出したいときにトラブルになる未来しか見えないが。

結局俺は次もext4+lvmにしてしまいそうだ orZ

Btrfs+zstd:1にしようぜ
容量が想像以上に圧縮できて驚くよ

今時容量不足で苦しむことなんてそんなに無いでしょ。

一般的なpcとディストリで気軽に使えてプロ相手にも十分通用する暗号化ってなんだろう・・・

>>852
zstd安定してる？

>>851
スナップショットのあるファイルシステムいいよ
いつでも全ファイルの差分が見えるし、バックアップ取るときもまずスナップショットを取ってそっちを対象にすれば
メインボリューム側では整合性期にせず作業続けられるし

>>855
Fedoraのデフォルトになって数年が経過しているから安心していいよ

Btrfsの透過圧縮でわざわざ標準外のレベル設定するのってだいぶ特殊用途なんでは…？

Fedoraチームがベンチマークを取ってzstd:1がベストと導き出したんだよ

5年以上 zstd で btrfs使ってたけど自分は問題無かった。
今はZFSでzstd使ってるけどこっちも問題ないよ。

>>860
btrfsからzfsにした理由とかある？

>>861
理由はproxmoxに移行したため。

純粋なストレージプールが欲しいならzfsやcephあたりで良いんだろうが
仮想化ゲストならvirtiofsが主流になって使いやすくなってほしいなぁ

>>862
サンクス

Ubuntu 23.10 Restores ZFS File-System Support In Its Installer

https://www.phoronix.com/news/Ubuntu-23.10-ZFS-Install

UbuntuはZFSを見棄てたわけではなかったみたい
次世代FSはbtrfsなのかZFSなのか……

ZFSはライセンス問題がある限りスタンダードにはなれんのだ

CDやBDだったら中がぐちゃぐちゃでもそれ片付ければ済むんだよ
焼くこともできない惨状

VDOつこうてる人おる？

あなるせっくす

結局またext4+lvmにしてしもうた

xfs+lvmでおk

もはやBtrfs以外は使わない理由を説明する必要があるレベル

btrfs難しいよ
どういう使い方が標準なん?

zstd:1で圧縮して時々スナップショットを取る使い方が標準だよ
バックアップを一瞬で取れるから派手にファイルを扱える

>>874
いうても同じボリュームにスナップショット取ってるんやろ？

スナップショットとバージョン管理は根本的に似てるような気もする
gitとbtrfsで何かfusionできないかな

言われてみると rsybc の差分バックアップで間に合うような気もする

rsync

俺は2005年くらいから毎日差分バックアップしたhomeディレクトリがある
当初はpdumpfsで途中からrsyncを使ってとったもの
つまりファイルに差分がなかったらハードリンクにして容量増加が抑えられる
ファイルとかハードリンクとかは当時から何も変わらないからまだ使えるんだけど
その下のストレージもfilesystemも開始した当時とは全く変わってしまった

普通の差分バックアップとBtrfsなどのスナップショットの違いは
ゴミ箱に放り込んだ後の挙動だね。
普通の差分バックアップは一応次のバックアップまでは容量が回復するけど
Btrfsのスナップショットだと、一度でもバックアップをすると
以降はファイル削除で逆に空き容量が減ったりという奇怪な挙動になる。

言いたい事は分かるがワケワカメ

スナップショットそのものをバックアップとして運用するんじゃなくて
スナップショットで瞬間を固定したものを別の物理ドライブにバックアップするんやで
使用中のデータをバックアップするよりも整合性の心配をしなくてよくなる

>>882
それ、スナップショットを別の物理ドライブに取ればええんでないの？

スナップショットの仕組みがわかっていない奴だな

昔使ってたストレージを思い出した。
データベース停止→同期ディスク切り離し→データベース起動→切り離したディスクからバックアップ→ディスク同期
データベース停止から起動まで5分だけど、バックアップは10時間とか。

スナップショットはバックアップではないと何度言えば解るのか

RAIDだってバックアップじゃないぞ！＞昔の俺

スナップショットも全部別ボリュームにバックアップや

俺はスナップショットを使ったことないんだけど
スナップショットってある時点のファイルシステムの状態を
保存できるというので良いのかな?
スナップショットってのは何回も取れると思うんだけど
するとこれらをバックアップしようと思ったら
他のストレージに複製する必要がある
それはフィルシステム階層でやるのかな? 複製されるのはフィルシステムのイメージ?
それともその上のcpコマンドとかrsyncでファイルとして複製するのかな?

バックアップ=一世代保管
の人には何でもよくね？

複数世代保管する場合は?

物理的な破損に対する対策をしたいのかデータ的な破損に対する対策がした以下によるでしょ。
よほどのことがない限りは通常利用でSSDが物理的に破損するなんて無いからスナップショットで十分だよ。