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

やっぱzfsは駄目だな
時代はBtrfs

BtrfsからZFSに出戻ったわ
特にスナップショット使いが難くてダメだった

子データセット(Btrfsだとサブボリューム)がある時の一括バックアップの使い勝手は
ZFSに軍配があがるなー

https://mao.5ch.net/test/read.cgi/linux/1514882734/922
btrfs のパフォーマンスが6.1で上がるニュースを教えてくれた人がいる

いっつもパフォーマンス上がってるな

……と思ったら今回は割とガチ目の上がり方だな
https://i.imgur.com/ShnaJKy.png

Open ZFSの更新来てた(∩´▽｀)∩

zfsの実際のrecord sizeはいつ決まるのでしょうか？
ググった範囲では、record sizeは(dataset指定サイズの範囲で)動的に決まる、決まったあとは変更されない(再作成が必要)、と認識してます。
ファイル書き込みはwrite(2)やfwrite(3)で行われると思うのですが、全てのプログラムが大きなバッファを用意しているとは限らない気がしてます。
zfsにはwriteback用にtxgという領域があるようですが、非同期書き込みのreocrd sizeはtxgがflushされる際に決定されるのでしょうか？
(もしそうであれば、同期書き込みはfsync(2)時に決定？)

NTFSクラスタサイズを後から変更するにはどのような方法があります？
フリーで探し手いるのですが、minitool や aomei無料版は非対応のようで。り

XFS & F2FS Changes Are Tame For Linux 6.1
https://www.phoronix.com/news/Linux-6.1-XFS-F2FS

Linux 6.2 Aims To Ship Updated Zstd Implementation
https://www.phoronix.com/news/Linux-6.2-Newer-Zstd

Zstd with Btrfs transparent file-system compression performance the decompression speed was "a small win across the board" and at lower compression levels the compression speed and compression ratio were both better than the prior kernel code.

暗号化鍵ってみなさんどう読み込ませてますか？
手入力だと強さに限界や起動時コンソール前にいる必要があると思うのと、何より面倒。。
かといって同じマシンに置くと平文になると思うので。

システムパーティションは暗号化せずにおいといて、盗まれたら困るデータだけ別のパーティションにおいてそこは暗号化している
起動したらSSH（SSHのサーバー鍵は「盗まれたら困る」には当たらない）して手でパスフレーズ入れて復号化
手入力の場合の強さの限界は、ストレッチングで多少は緩和される。

BitTorrent File System (BTFS)
https://www.bittorrent.com/token/bittorrent-file-system/

なんだこれは・・・たまげたなあ

これが本当の分散ファイルシステム

概念的には昔からあるが今のインターネットじゃいろんな部分の性能保証がないから実用性がね

赤帽エンジニアブログ
2022-12-01
XFSで使った以上に容量が減るナゾ

リンク貼れんかったので

ファイルシステム関連のドキュメントはBtrfsもxfsもOracle Linux のが親切だな。
https://docs.oracle.com/en/operating-systems/oracle-linux/9/

Oracleは宗教上の理由でちょっと……

https://www.phoronix.com/news/Linux-6.2-Btrfs-EXT4
6.2からbtrfs raid5の信頼性が上がるらしい

zstdもアップデートされて高速化されるみたいだし6.2は重要なアップデートになるな

exfatも6.2で速くなるみたいだな

6.1 が重要そうで、Debian のコードフリーズに間に合って喜んでいたんだけど...
カーネルだけならアップデートしてもほとんど失敗しないし、別にいいんだけど。

昔はshutdown -rFでfsck走ったけどbtrfsは気にしなくていいの？
VMシャットダウンした時とかに気になって。

shutdownコマンドは古くて問題があったので廃止されてる
systemctlを使おう

使ってるのだが...

今は大抵shutdownとかもsystemctlへのリンクになってるやろ

ホントだ
shutdownとして呼ばれると適切に読み替えてくれるんかな?
# shutdown -r now
# shutdown -h now

普通にpoweroffかrebootが1語で済んで簡単で良い

ファイル名の長さ制限なんとかならん?

前は制限あったけど、今もあるっけ？

ファイルのダウンロード中にLinuxのext4ファイルシステムが突然クラッシュしてOSが動かなくなった。
保存先のディレクトリのファイルがすべて操作不能、削除不可能状態になった。
物理的な衝撃とかもまったくなく、突如として起こったトラブル。

再起動したらLinuxはうまく立ち上がらず、セーフモードに。
けっきょく再インストールするハメになったが、インストールに失敗する。
いろんなディストリを試したが、どのディストリでもインストール中にエラーが出て止まる。
インストールメディアの破損もなければ、HDDの破損もない。
DVDドライブも普通に焼くことができるのに。

こんなことがあるんだね。安定しているファイルシステムはなんだろうか。

>>621
無制限なのはパス名の長さで、ファイル名はほとんどのファイルシステムで長さに制限があるはず

>>624
>>622
安価ミス

>>623

> こんなことがあるんだね。

ビジネスだと物珍しいレベルではないかな。
最近は出荷前検査の精度が上がってて初期不良減ってるから物珍しいレベルになりつつあるけど。

症状的には CPU/マザボ 故障が疑わしい。 その次はメモリ。
ドライブもファイルシステムも無罪だと思うわ。

つうか、ext4 ってまともなメンテナ居るのか？
ドライブ故障のトレンドに追随できてないファイルシステムは使うべきではないよ。

>>623
ZFSならsnapshotからロールバックで戻せるんじゃない？

>>622
ext4が255バイトでNTFSが255文字（Unicode16）なんで困るんよ
vfsにハードコードされてるぽいんでダメだろうけどダメ元で聞いてみた次第

流石に無知がすぎるだろ
ext4なんて現在進行系で開発されまくってるファイルシステムだぞ
あと絶対に壊れないファイルシステムは無いから
ext4よりbtrfsやzfsのほうが壊れにくくはあるけれど

>>629
本当に開発されまくって言えるか？
Red Hat 系使う奴は xfs ばかり使うし、その他のディストリも btrfs だったり。
ファイルサーバ製品もハード直結独自FSばかり。
ext4 は使われていない/充分なデータが集まっていないだろ。

6.1でのext4の変更
https://lore.kernel.org/lkml/[email protected]/

ext4が使われてないってどこの世界線なんだ…
クラウドではほとんどext4だろう

>>632
amazon も ext4 やめて xfs でしょ？

ここのベンチマークの結果だとext4は速い方なので、いい印象持っている
https://hesonogoma.com/linux/filesystembenchmarkresults-02.html

ファイル名については昔Linusが255バイト制限緩めても今度は1MBじゃ足りないっていい出すに決まってるから対応しないって言ってなかったっけ
東アジア圏だとutf8で更に厳しくなったけど、今ならファイル名に長々情報持たせるほうが悪いって言われそうだしな

英語圏の人は漢字圏特有の問題を理解しないからな

使えるパスの長さは AIX や Solaris の方が少し制限が緩いようにも見えるし、文字コードがUTF-8 じゃなかった頃の設計のせいにも見えるね。
https://www.ibm.com/docs/ja/spectrum-protect/8.1.9?topic=parameters-file-specification-syntax

OpenShift4 のPVはext4だった気がする。間違ってたらスマン。

>>638
デフォルトはね
設定で変えられる

linuxの文字数制限が不便でNASを使用しなくなったことがある

ファイル名がUTF-16で記録されるexFATだとLinuxでも全角文字255文字フルに使えたからファイルシステムによるんじゃない？

fusuで実装されてるからでは？

>>639
なんと。。圧縮したかったのでbtrfsで圧縮出来ればいいなと思ってた。
RedHatだから無理かな。。

ログを延々と吐き続ける用途にbtrfsは向いてますかね？
CoWが邪魔したりしませんか？

GpartedでUSBメモリをexFatでフォーマットしている途中で進捗が止まり、そのまま。
USBメモリがどうやら物理的に壊れてしまった。
PCに挿し込んでもそのUSBメモリだけがまったく反応なくなった。
Linuxのインストール途中で失敗しつづけている。

悪いこと続き。Linuxの神様に見放された模様。

邪魔の意味は分からないけど、性能はともかくデータ化けとかの心配は無いのでは？
CoWが提供するのは堅牢性や一貫性確保だと思う。
CoWがダメならzfsにはログ保存できないことになってしまうし。。

ZFSはブロックレベルの重複排除だからCOWでも問題無いとかの話？

ログファイルってコピーして使うか？
普通しないからCoWが邪魔はしないでしょ。
ランダムアクセスするファイルならRAIDで向き不向きあるけど
ファイルシステムで向き不向きはないと思う。

データベースやVMのディスクイメージみたいな1つのファイルを何度も上書きするパターンはCoWと相性が悪いと聞くな
当該ディレクトリのCoWを無効化すればいいけど、してもI/O性能が上がる程度で有効のままでも別に問題なさそう

Btrfs の場合、CoW有効のファイルを書き込んだ後に以前書き込んだ部分を上書き
するとドライブ上ではそのブロックを上書きせずに別ブロックに書き込む動作をする。

「ファイルコピーしたファイルでのみそれが発生する」と思っていたがそれは俺の
勘違いで、実際は全ファイルでそれをやるってことか。

まあでもログファイルはシーケンシャルアクセスだから(ブロック単位の
上書きは発生しないから)CoWが邪魔しないことに変わりはなさそうね。

ログで質問したものです。
皆さんありがとう！
色んな考察が聞けてためになりますた。
VMはCoW無効にするのが常識とおもってて、
ログとかの追記も関係あるのかと思った次第です。
とりあえず何もチューニングせずに使おうと思います！

debianのtestingに降りてくるまで一月ほどかかるなぁ

ext4はシステム向け、xfsは倉庫向けと考えてok?

どうしてそう思った？xfsデフォのディストリもあるが

大きいファイルなら速いけど壊れやすくメモリ食うのがxfs縮小もできない
ext4は逆

>>653
RHEL9 から dump/restore は OS に添付されなくなった。
何かあっても保守/問合せ対象外。
EPEL として残ってるから完全に対象外というわけではないだろうけど。
その観点でいうと ext4 はコンテナ向け、xfsは物理向け、なのかも？

じゃあbtrfsはなに向け？
てかbtrfsはscrub定期的にしないとダメなの？

zfs にコンプレックスを感じる人向け、というのは冗談として
ext4 の後継と思っている。

>>658
やっぱそういう位置づけだよね？
何故かQNAPはbtrfsをディスってるけどw
https://www.qnap.com/solution/qnap-ext4/ja-jp/

>>659
草
BtrfsでNAS作られると（高機能すぎて売りが無くなるので）困るというのが伝わってくるw

Linuxのファイルシステムはどれも一長一短で決め手にかける。「用途とか関係ない、これにしておけばまずOK」ってのがない。
ext4は大容量ドライブでfsckが遅く昨今の大容量なディスクドライブに作成するには向かない、
xfsはfsckは大容量ドライブでも問題ないが縮小ができないしメモリも食う、
btrfsはfsck不要、CoWなど「モダンなファイルシステム」とされるが、比較的新しいファイルシステムでやや心配がある、枯れていない、遅い。最近はまともになってきているが。
ZFSはライセンスの問題・・・

一方、選択肢が多いのは良いこととも言える。他のOSだって問題はいろいろあるし、OS、FSともに完全無欠のものはないけどね。

Debian系はデフォルトext4なのは何でだろ

>>661
xfsって壊れやすいって本当？
なんかレガシな感じがして受け付けないんだよね。
そういやreiserfsはタイーホ後からどうなったのかね？
当時は先進的だったけど。

>>663
reiserfsは非推奨になってて2025年に削除される予定

ファイルサーバーにZFS使ってるけど安定してる
RAIDZ2組んでて一度HDDが一つ壊れたけど復旧も簡単だった

ZFSはARCが重いんだよな
LRUよりは効率的だけど計算量が多いわ

>>663
xfsはCOW導入で安定性が落ちたという話は聞いた気がするけど、その続報を聞かないな。話題になってないってことは安定したのか、皆避けてるのか

xfsは近いうちに縮小サポートするつもりがあるらしい
https://www.phoronix.com/news/XFS-Defragment-Free-Space

圧縮ファイルシステムでおすすめを教えて
主にテキストのログをどんどこ吐きたい

btrfsかF2FSかな
ログ出力用途ならF2FSのほうが向いてそう

金持ってたらgpfs使いたいんだけどな
安定性は元々HPCやエンタプライズ向けだから折り紙付き
パスは255"文字"だしPOSIXで圧縮・暗号・ネットワーク共有・スナップショット・SSDキャッシュ等々
たいてい何でもあり、重複排除はあるのか知らんが

分散ファイルシステムならcephでよくないか

完璧ファイルシステムないよな
文房具みたいなもんでやりたいことがいろいろバラバラなんだろうな

当初から設計にも実装にも問題がなければ個人ユースではbtrfsがさいつよだったんだろうけどな
余りにも不具合が多過ぎた過去があって未だに怖くて使う気にはなれない

最近は不具合聞かんね

btrfsだから不具合の噂が広まるみたいなところもあったと思う
去年か一昨年あたりにLinuxのext4がぶっ壊れてた時期があったけど別に広まってないし

ext4とは頻度も不具合の数も全然違ってた
動画かスライドショーか忘れたけど当時のバージョンのbtrfsを意図的に壊す色々な手順を紹介してた
強引にじゃなくって長年使ってればそういうケースもあるだろうって手順だったからな
全員って訳じゃないが当時を知ってる人の多くは使い始めるのに躊躇するんじゃないかね

みんなが寄ってたかっていじめ抜いて鍛え上げられたFSとかむしろ信頼できるという発想

Copy-on-write のファイルシステムは、良い面もあるけど想定のパフォーマンス出ない時や、使わない方が良いケースを理解できたのは btrfs のおかげ。

cgroup v2に対応しているファイルシステムがbtrfsしかないからコンテナを厳密に運用しようとするとbtrfs使うしかないんだよな
Facebookがbtrfsを使ってる理由がこれだったはず

ミラーリング対応してるファイルシステムはZFSとbtrfsくらい？

btrfsってもしかして面倒くさい？
空き容量少なくなってくるとSSDでもランダム書き込みが遅くなる
ファイル消してもメタデータが容量を食っている

btrfs使うなら定期的にbalanceしないとダメ？

倉庫用HDDなら、
ファイル圧縮
チェックサム
誤操作での削除防止や他ストレージへの差分バックアップにスナップショット

とかでbtrfs特有機能が生きてくる気はする
だがシステムドライブは安心と信頼のext4で良いんじゃないかと

あるいは、nodatacow使えば一つのパーティションで
非COWとCOWのファイルシステムの
両方のいいとこ取りが出来る？

ファイル消して容量減らないのはメタデータなんかじゃなくて以前スナップショット切ったとか、コピー元ファイル残ってるとかだゾ。全く食わんとは言わないけどメタデータそんなに容量食わない。
空き容量減ってランダム遅くなるのはSSDってそういうもんだ。
/homeはスナップショットや圧縮がすげー生きるよ。

仮想ホストとゲスト両方共にbtrfsにしたのは失敗だろうか。。。

btrfs、ファイルを削除してからdfコマンドで見える空き領域が増えるのには少し時間がかかる
長いときでも5分とかだけどね

>>684
その書き方だと仮想マシンのイメージファイルもbtrfsのファイルシステムにあるのか？
仮想マシンのイメージファイルとか、データベースのファイルみたいなファイルをbtrfsに保存するときはCoW無効化しておくほうがよいぞ

半導体不足で納期が悲惨な頃にNASが壊れて、急場しのぎで作ったbtrfs+snapperが好評過ぎて今までズルズル使われてしまった。壊れるの嫌だから全くイジってなかったけれど、退役後に色々試すの楽しみ。kernel上げだけでも楽しみ

>>685
レスありがとう。
いちおうゲスト格納ディレクトリには
chattr +Cしてるけど、大丈夫かな。
ゲストの中身もbtrfsなんだよな。。。
NASとかでないのでオーバースペックだったかと後悔しそう。
新しいモノ好きだから飛びついてしまったよ。

ファイルを作成したあとにchattr +Cしてもダメやで
正しいやりかたはググって調べてね

おっと、空ファイルに対するchattr +Cは有効だった。詳細は調べてね

>>688
作成する前は良いということですね。
ありがとうこざいます。
これってディレクトリに対してのみでファイルには無効でOK？

>>690
ディレクトリに設定したら再帰的に適用される

>>691
間違えた
新しく作るやつは再帰的に適用される