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

今fstabでcompress=lzoとかしてるんだけど、既存のファイルは別に今すぐzstdにしなくていいけど今後作られる新規のファイルとかはzstdで圧縮してほしいと思ったらcompress=zstdにするだけでいいの？

上記に書かれてるのはcompress=zstd:1かな。
自分はcompress-force=zstd:1にしてる。
zstdはアルゴリズム自体に圧縮の可否の判定コードが組み込まれているから
compress-forceでも問題ないらしい。（実際に使ってるけどデメリットは感じない）

BtrfsもZstandardもFacebookが本番環境でゴリゴリに利用しながら開発協力してるから進化が早いね

リーナスがbtrfsの時代を見越して特権でマージしてからはや12年
やっといい感じになったのか
一時期の停滞はなんだったんだろうな

compress-forceはやめたほうがいいぞ
画像や動画や音声みたいにすでに圧縮されていて圧縮する意味がないファイルまで圧縮するから

だからそれをzstdなら自動で判定してくれるって話なんじゃないの？
俺はcompress=zstdにしてるけど

>>362
zstdなら自動判定で圧縮出来ないファイルは無視するから大丈夫だよ
compress-force=zstd:1でこんな感じ
https://i.imgur.com/G535ZqH.png

forceとはいったい……

>>364
そんなの見れるんだ、コマンド教えて

zstd以外の圧縮形式だと本当に全部圧縮する
zstdは賢いからforceで問題ない

>>365
https://github.com/kilobyte/compsize

>>366
おー、Debianにもパッケージあるし、見れた。ファイルサーバで試したら思ってたよりすげー圧縮してたわ。
ありがとう。

まじでここ最近のBtrfs進化凄まじいな
圧縮によってSSDが長持ちする効果も。
個人ユースレベルの話だけど、fedora34、35と使っててトラブルなし

>>366
横からですがGJ！

kernel 5.16でbtrfsパフォUP
ttps://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Linux-5.16

qemuイメージをbtrfs上で使う場合、どのような方法がオススメでしょうか？ thin provisipningが目的で、qcow2自体のsnapshotや圧縮は使っておりません。
・qcow2+nocow(btrfs)
・raw+cow(btrfs)
・raw+cow(btrfs)+compress(btrfs)
・raw+nocow(btrfs)
・その他など

thin provisioningがディスク容量の削減を指すんだったら
qcow2の圧縮にzstdを使ったら「初期イメージは」RAWの
20%以上ぐらい？まで縮んだなあ…
debianインストール済みイメージで、/はext4、ディスク使用量
約2GBで、イメージサイズは300MB台だった記憶
インストールして初期イメージ作成までは一旦RAWで作って、
空き容量いっぱいにddでzero埋めファイルを作ってから削除、
それからqcow2変換ってことをしたけど

圧縮方式はデフォルトでzstdは勘違いだった

牛さんパワーktkr

うーん、btrfs上のqcow2はcowだとパフォーマンス劣化が激しいという記事や、btrfs NOCOW filesにはchecksumや圧縮が効かない？ようなんですよね。。
https://btrfs.wiki.kernel.org/index.php/Compression#How_does_compression_interact_with_direct_IO_or_COW.3F
ならば、cowや圧縮はqcow2ではなくbtrfsに任せるよう、rawが良いのかなと考えたのですが、ネットに事例見当たらず、考え違いしてないか気になりまして。。

自分は/homeとか/varとか、書き換え頻度の高そうな
マウントポイントだけ分離するために別のRAWイメージファイルを
作成して、メインのqcow2イメージとは別に
追加でマウントとかしてた
例えばqemu内のfstabでは sdb1を/var とか sdb2を/home とか

頻繁に書き換えのあるディレクトリだけを
別のディスクイメージにまとめて、/のファイルシステム上では
そこへのシンボリックリンクにしてしまってもいいかも

みなさん、アドバイスありがとうございます。
rawにした方がパフォーマンスはいいけど、qcow2の方が他のメリットがあるから？使う人が多いような印象を受けました。
rawを試してみようと思います。

Btrfsは開発が活発で気持ちいい
https://btrfs.wiki.kernel.org/index.php/Changelog
これなら最新カーネルを使おうという気になるね

いやならないけど

使ってみようかなという気にはさせるねバター FS
新しいハードディスク買ったんだけど今回は zfs から変えてみた

「Btrfs」って「バター FS」って読むの？
「ビートゥリーFS」って読んでたや

Windows機からLAN経由でLinux機の共有フォルダにアクセスした場合に
Linux機の共有フォルダがext4でフォーマットしてあるHDD上に作られているにも関わらず
Windows機側から問題なく読み書きできるのは何故なのでしょうか？

Windows機にはサードパーティ製のext4ドライバをインストールしていないので不思議です

ext4じゃなくてCIFSを読んでいるからです

>>382
レス有難う御座います
てっきりデフォルトのWindowsがext4を読めるようになったのかと思っていました
Windows機とLinux機で使えるように外付けHDDをext4でフォーマットしようと思ったのですが無条件では無理なんですね

>>381
sambaはSMBを喋るからね

ここ１ヶ月ほどでbtrfsのエラーが急に増えたのですが、このエラーの直し方ご存じの方いますか？
デバイスはWDS512G1X0C nvmeです。

Dec 20 10:24:57 xxx kernel: BTRFS warning (device nvme0n1p4): csum failed root 257 ino 284 off 101092372480 csum 0x3423b0e6 expected csum 0xb17c434b mirror 1
Dec 20 10:24:57 xxx kernel: BTRFS error (device nvme0n1p4): bdev /dev/nvme0n1p4 errs: wr 0, rd 0, flush 0, corrupt 1453, gen 0

$ sudo btrfs dev stat /disk/btrfs_nvme0n1p4
[/dev/nvme0n1p4].write_io_errs 0
[/dev/nvme0n1p4].read_io_errs 0
[/dev/nvme0n1p4].flush_io_errs 0
[/dev/nvme0n1p4].corruption_errs 1457
[/dev/nvme0n1p4].generation_errs 0

それ破損エラーたけど
SSDが壊れているのでは？

ZFSの機能について質問させて下さい
スナップショット・ブックマーク・チェックポイント　それぞれどういうものでどう機能するのでしょうか
今のところバックアップや有事のrollback等、スナップショット機能+sendくらいでニーズは満たしてはいるのですが

>>385
$ sudo btrfs dev stats -z /disk/btrfs_nvme0n1p4　でステータスリセット後にscrub
それでも同様になるならストレージ交換を推奨

エラーが急に増えた、とかいうことはまだ読めるんじゃないか
それだったら先にデータをバックアップしたほうが良くないか？

それもそうですね
dev stats 使える人ならばたぶんバックアップのやり方も知っているでしょう

そもそもファイルシステム関係あるの？

どっちかと言えばハードウェアの領域か

>>386,387,388
アドバイスありがとうございます。
エラーはhw故障の可能性でしたか。。
バックアップは取りました。
btrfs scrub、試して様子見てみます

385 (369)です。
btrfsのcorruption_errですが、原因が(多分)判明したので報告します。
原因はDirectIOだった様です。
ttps://www.reddit.com/r/btrfs/comments/pwkkmj/comment/hepr7ct/?utm_source=share&utm_medium=web2x&context=3
ttps://www.spinics.net/lists/linux-btrfs/msg25940.html

自分の場合、qemuでWindows guestをqcow2 image(NoCoW,nocomp)、cache mode=none で使っており、raw(CoW,comp)に変更した後もcache mode=noneのままでした。writebackにしたらcorruption_errが発生しなくなりました。
btrfsのDirectIOは、NoCoWでは問題ないが、CoWだと問題がある(？)ようです。
ttps://lwn.net/Articles/442355/
ttps://bugzilla.redhat.com/show_bug.cgi?id=1914433#c19
ファイルシステムのDirectIOを使う際は、Stable pages(？)もチェックしておく必要があるということを初めて知りました。。

btrfsのDirectIOについては、ttps://btrfs.wiki.kernel.org/index.php/Gotchas#Direct_IO_and_CRCs に記載されてました。

$ timeshift-launcher &
で　あるスナップショットで　非共有サイズが109メガバイトだとして、具体的に以前の状態からどんな変更をくわえたかの
具体的情報は、どうすればわかるのでしょうか？

OpenZFS 2.1.3 Released With Many Fixes - Phoronix
https://www.phoronix.com/scan.php?page=news_item&;px=OpenZFS-2.1.3

TimeshiftでRsyncでバックアップしたのですが、
RestoreしようとするもInvalid argumentと出てRestore出来ません。
TimeshiftみたいなのってVPSでは使えないものなのでしょうか？
ちなみにbtrfsでフォーマットされたパーティションです…

引数間違ってるって書いてるやん
間違えてるんでしょう

>>397
更新内容
Release zfs-2.1.3 ・ openzfs/zfs ・ GitHub
https://github.com/openzfs/zfs/releases/tag/zfs-2.1.3

うちは全てのマシンにUPSをおごる金など無い
昨日の大規模停電は図らずもファイルシステムの信頼性を確認する出来事となった
電力回復後fsck的なものも走らず復旧するZFS・Btrfs　つよい

Debian ではいつインストーラーにOpenZFSを付けてくれるんだろ。
https://wiki.debian.org/ZFS
xfs に関しては、上記のwikiには記載ないとかドキュメント化で差があるけど。

mainパッケージ入り出来ないうちは無理なんじゃね

Btrfsについにブロック単位での重複排除が来た
https://github.com/Zygo/bees

マジ！！？

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

ユーザースペースのなら前からあったような

10TBあたりわずか1GBのハッシュテーブルを使用できます
ファイルシステム全体の重複排除-スナップショットを含む
btrfs圧縮で動作します-圧縮ファイルと非圧縮ファイルの任意の組み合わせを重複排除します
デーモンは、btrfsツリー検索を使用して新しいデータを段階的に重複排除します
シャットダウン後の迅速な再起動のための永続的なハッシュテーブル
データセットが大きくなってもRAM使用量は増加しません
ライブで動作します-スケジュールされたダウンタイムは必要ありません

おいおい神か！？
もうzfsを使う理由がなくなってきたな

raid6はいつ安定しますか…？

>>408
> データセットが大きくなってもRAM使用量は増加しません

これってZFSだとメモリ食うやつだよね？
ZFSしか使ったことないけど次は調べてbtrfsするかな

ext4でいいじゃん・・・

Fedoraで2年間Btrfsを圧縮有効にしてtimeshiftも使ってるけど一切不安定になったことがない。
以前にDebianでBtrfsを試して即座にデータが吹き飛んだ頃と比べると相当安定してきたと感じてる。
最新のカーネルを使えるなら今はBtrfsが第一選択肢でもいいんじゃないかな。

・空き容量が不正確
・空き容量カツカツでの運用は非推奨
・scrubを定期的に実行しないといけない
・vmイメージの置き場所にはあまり適さない
・ext4と比べると容量食い
ってな感じのことを聞いたんだけどほんと？

・btrfsユーティリティが正確な容量を教えてくれる
・空き容量カツカツは大抵のフォイルシステムで非推奨じゃね？
・定期実行しなくても問題出ない
・VMイメージの置き場所には適さないけどオプション指定があったような
・透過圧縮もあるのでむしろ食わない

・ちんちんシュッ！シュッ！シュッ！

イメージ置くならlvm推奨、raid5,6使うならdevice-mapper推奨、quota使うならxfs推奨

VMイメージやDBファイルについてはCoWを無効化した方が良いとArchWikiにあるな
ファイルやディレクトリ単体で無効化できる模様

自動でその設定してくれんかな
sqliteとか多すぎて手動で設定するの大変だよ

パフォーマンス追求するケースの話であって一般的にはそこまで困らんでしょ

>>417
chatter +C dir
だけで良いのでしょうか?

CoWを無効にすると圧縮も無効になるから一長一短だよ

多少性能低下するだけだしVMディスクイメージはCOW有効化するな
無効化したらスナップショットからのお手軽ロールバック出来なくなるし

スナップショットをVM Consistentでとれる確証がなければ、やめておいた方がいいよ

>>413
・ツール類に信頼がおけない

EXT4の感覚でUUIDを変更したら
特に警告等なく完了したがその後エラーを検出してファイルにアクセスできなくなった

>>413
空き領域まわりは強いクセがあるな
btrfsの場合は常に5GB以上は空けておかないと安心できない

btrfsは未使用領域を"chunk"と呼ばれる1GB（公式の説明）のブロックで切り出してから書き込むが
切り出すときに用途を固定してしまう（実データ・メタデータ・システム）
全ての未使用領域を切り出したあとにメタデータ領域が枯渇すると実データ領域に空きがあっても一切のファイル操作ができなくなる

ファイルの削除は可能だが空き領域が回復しないことも多い
メモリ上では削除成功したことになってもディスク上ではメタデータの更新に失敗するため
こうなったら復旧するには特殊な手順が必要になる

NTFSはフォーマット時にメタデータ領域を切り出すが
空き領域が枯渇するとメタデータ領域を実データ用に転用したり、メタデータ領域を拡張する仕組みがあるので
最後まで表示通りに書き込みができる
その代わり断片化が激しくなる

なる
パフォーマンスを取るか緩く安定を取るかみたいなもんか

空き容量はメタデータ云々といよりスナップショットの関係だよ
スナップショット取ってる場合には、削除が空き容量の増加にならないからという単純な話
スナップショット使ってないパーティションで何度も空き容量不足になってるけど一度も壊れた事はない (カーネル5以降の話)

サーバーはともかく
デスクトップPCならBtrfsに切り替えても問題ない頃合いだね
Fedoraがデフォルトにしてしばらく大きな不具合は見つかってないし

なんかええんかそれ

レッツビギン　使ってみればわかるさきっと

未だに10年前と同じ感覚でbtrfsを語ってる人たまに居るよね
くっそ古いカーネル使ってるならその認識で合ってるかもしれないけど

ファイルシステムはカーネルバージョンでガッツリ変わるからな
btrfsだけでなくext4やxfsも変わってる

怖いのはFS信頼性よりヒューマンエラー(ヒューマンとは俺自身含む)と思ってる
有事への備えさえしておけば先進のFSでも大丈夫
ラズパイですら再フォーマット無しにほぼ放置で２年ちょっと経過

今でこそBtrfsを愛用しているけど
カーネル4.xx時代はヒューマーンエラーとかいうレベルじゃない不安定さで使い物にならなかったよ
前兆なしでサルベージすら不可能な壊れ方するからヤバかった

使用開始時はさすがにおっかないFSだと言う認識はあった
当時のラズパイOSのカーネルはよく覚えてないけど5.4.*とかだったかなぁ

ラズパイでの試験運用開始時は十重二十重にスナップショット取ったり
日時バックアップしたりを欠かさなかった

調べるとBtrfsは丁度カーネル5.4から安定してきたらしい
確かにそのくらいからBtrfsユーザーの阿鼻叫喚が鳴りを潜めた気がする

「ラズパイだからいいややってみよ　バックアップも取るし」くらいの安易な気持ちだったのを覚えている
運が良かったのか引きが強かったと言えるのかわからんけど特にFSが飛ぶ事も無く現在に至る
使用開始後調子に乗ってPCでも使い始めるまでにそれ程時間はかからなかった

ふっるいカーネルと言われると3とか4あたりを想像するわ
5.4ってまだ2〜3年前くらいじゃね

従って今日はそのふっるいカーネルの感覚で語ってる者はいないと言う事だな

Fedoraはdnfインストールでreflinkを扱ったりと
既にBtrfsの利用を前提とした周辺ソフトウェアの最適化に取り組んでたりするから
他のディストリにも成果が流れてBtrfsがデフォルトになっていくだろうね

ZFS みたいにメモリが沢山ないとパフォーマンスが出ないみたいな低スペ野郎は使えない制限はBtrfsにはないんですか？
ext4 と比べるとディスク容量は少し食うみたいですが。

XfsでCoW有効にした時にはメモリ食いすぎて常にカツカツだったけど
Btrfsは省メモリで特にロースペに厳しいとかはないね
透過圧縮も普通に有効にしてる

btrfsもそれなりにスペック依存性あって、
職場NASをHP ProLiant MicroServer(Athlon II NEO N36L)から
Ryzen 5 Pro 3600自作機に更新したらメチャ早くなった。どっちもCentOS7。

なので試しに自宅NAS(4HDD@UbuntuServer)を200GEから2400Gに変更したら早くなったので、
今は欲を出して余りHDD全部(4x3.5CMR, 4x2.5CMR, 1x3.5SMR)を繋ごうと考えてSATAカード物色中。

BtrfsというかZstdの進化が凄まじいから
なるべく最新のカーネルを扱えるディストリの方がいいよね
今だと公式にBtrfsをデフォルトにしてるFedoraがベストかな

Btrfsのカーネル選び
5.4〜　安定化(事実上これ以前は非推奨)
5.16〜　Zstd圧縮のパフォーマンスが大幅に向上
Ubuntu 22.04でもカーネル5.15だから入れ替えないならFedoraしかない
本格的な普及はサーバー向けの定番ディストリに5.16が降りてくる来年以降かな

ほなCentOS Stream使いましょうねえ

>>447
先生、質問です。
CentOS Stream はインストーラがBtrfsに対応していますか？
RHEL が Btrfs を利用しないとインストーラに出てこない気がしました。

インストーラが対応してないどころかbtrfs-progsのパッケージもないしそもそもカーネルが対応してない
自分でビルドして入れれば使える

先生スパルタ過ぎませんか…？

僕はArchで行きます

CentOS Stream だと、/ に一式インストールした後、カーネルのリビルドして、必要なパッケージ入れて分ける予定のパーティションはその後フォーマットして色々移動させてから、残りは btrfs-convert でext4 から Btrfs に変換するんかな。

昔はデスクトップでArch使ってたけど
BtrfsやZram等、結果的にFedoraのデフォルト構成に近い部分が多くなって
だったら最初からFedoraでいいじゃんと思って以来ずっとFedoraだな

今、透過的圧縮対応のファイルシステムって何が主流なんですか
バターFSですか

デスクトップ用途だとFedoraのデフォルトインストール設定が
Btrfs+zstd圧縮だから圧倒的にBtrfs
サーバーだと実績を考えてまだ無難なZFSで動かしてるケースが多いんじゃないかな

ZFS ハードル高いのとRHELはxfs、Debianはext4 だと思うけど。

xfsはRedHatがBtrfs駄目だからって言ってCOW持ち込んだらすげーぶっ壊れになったり、32bit環境で致命的なバグ出した事あったり、急に鉄板ハイスピードFS扱いになったりととにかく評価が安定しないイメージ

RedHatは社内にBtrfsのメンテナがいないから導入予定はないらしい
Btrfs側のバグが原因で不具合発生した場合にRedHatで解決できないのが理由かな

>>455
透過圧縮の話題だぞ

ちんちんシュッ！シュッ！シュッ！