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

あとは透過圧縮で利用するzstdの改善が5.13で入った
安定面ではなくパフォーマンス面で考えるとカーネル5.10だともったいない気がする

ZFSはまあまあメモリ食う時もあるけどあまり気にした事ないな
心配ならARC制限すればいいし
Btrfsはパフォーマンスが上がるのか
個人レベルでは問題視する様な不具合は見てないし今後がますます楽しみ

>>329
知らなかったから調べてみたらBtrfsでzstd圧縮を利用している場合5〜15%パフォーマンスアップとあるね。必須とまでは言わないけど、あれば嬉しい感じ

ext4でcrc32c_intelが有効になっているか確認する方法ありますか？
カーネルモジュールは組み込まれていて、
dumpe2fs -hで見ると、crc32cとだけ表示されています。
intelの使ってるのでしょうか…？

https://wiki.archlinux.jp/index.php/Ext4#.E3.83.A1.E3.82.BF.E3.83.87.E3.83.BC.E3.82.BF.E3.83.81.E3.82.A7.E3.83.83.E3.82.AF.E3.82.B5.E3.83.A0.E3.82.92.E6.9C.89.E5.8A.B9.E5.8C.96.E3.81.99.E3.82.8B
https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums

今やwindowsでもBtrfsは使えるんやで
https://github.com/maharmstone/btrfs

EXT4って巨大ファイル（数十GB〜数百GB）のファイルを削除しようとしたらめちゃくちゃ遅くない？
ずっと前からそうで久々に新しいシステムセットアップして最近は改善されたかな？と思ったけど同じだった

ext3じゃなくて？

ext4でもそうなんだよな

inodeに削除フラグ立ててるだけならおかしいよね
SSD のハードウェア側で何か処理が行われているのかな

まさかマウントオプションでTrim有効にしてないか？

ext4は昔からNTFSと比べると削除は遅いよ

On-Disk Format Changes Ahead To Improve "Painful" Parts Of Btrfs Design

https://www.phoronix.com/scan.php?page=news_item&;px=Btrfs-Improving-Painful-Parts

そろそろ安定してきたっぽいからbtrfsに乗り換えようかと思ってたけど
来年Disk Format変わるのかよ……

そうだとしても乗り換えてOKでしょう
Fedora34でBtrfsにして35へのアップグレードも済ませたけど相変わらず安定だよ
即座に壊れたカーネル4.xx時代とは大違い

Fedoraが透過圧縮有効のBtrfsをデフォルトにして問題なしだから
カーネルさえ新しければデスクトップ用途ではまず問題は発生しないと思う

Fedora の方がRedhatの見立てより正しかったのか。
xfs Cow を頑張るべきかで楽しみ増えたね。

見立てが正しいとかじゃなくて性質の違いじゃないかなあ。
半年ごとに新しいバージョンが出て、サポート期間が1年のものと、
10年近くサポートしなければいけないものでは、物事の決定が大きく変わるよ。
Fedoraで徹底的にbtrfsのバグを潰して、RHELに再導入したいんじゃないかな。
ちゃんと動くなら、btrfsはどう考えてもRHELの売りにはなるから。

RHELは単純にRedHatの従業員にBtrfsのメンテナが居ないという理由だったはず。
Btrfs側にパッチを当てる権限がないと商業利用でメインに据えるのは難しい。

bcachefsを使ってる方いますか？使い心地を伺いたく。
たまにしか使わないvmを、使うときはssdの速度、保存は大容量のhdd、といいとこ取り出来たらいいなと思ったので。

Bcachefsはやめときな。
開発が事実上個人に依存している上に
Btrfsが安定化した今となっては存在意義が薄れてる。

BcacheFSの作者にはPatreonで投げ銭してたけどBtrfsが普通に快適で順調に安定性も上がってるようだったから投げ銭止めちまったな。

>>348
>>349
ありがとうございます。
このスレでも使われてなさそうで、常用はまだまだという感じました。
大人しくメインライン入りを待ちます。

いや、メインライン入りしても使わないほうがいい
Bcachefsはリソースが足りてないから常用はまだまだというか多分無理
素直に安定化したBtrfsを利用するのがおすすめ

結局のところBtrfsの圧縮はlzoかzstdどっちがいいのか教えて偉い人

>>352
zstd:1一択
FedoraチームがCPU使用率と圧縮率のバランスから検証した結論
自分も1年以上zstd:1で運用してるけど快適そのもの

マジか。長らくlzoだったけどzstdにするかな?
RaspberryPi4な自宅ファイルサーバだからCPU弱いけど

zstdが進化しすぎてlzoはもはや存在意義がない
圧縮率、圧縮速度、解凍速度、全てでzstdが上回ってる
しかもzstdは未だにアルゴリズムの改善による高速化が続いてるから差は広がるばかり
強いて弱点を挙げるなら古いカーネルとの互換性くらいかな

zstdの圧縮アルゴリズム自体が負荷が少なくて
しかも圧縮率でもほぼ全てのケースで
gzipとかの系統の圧縮方法より縮むみたい
(さすがにlzoよりは多少負荷かかるだろうけど)

将来的にgzip使ってるとこをを完全に置き換えそう
自分でもarm系の非力な環境でtarに使ってると
時間ベースで倍以上早い感じ

開発中の5.16カーネルでZstd更に速度アップ（四年前のコードが新しく）

今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以降の話)