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

>>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
間違えた
新しく作るやつは再帰的に適用される

>>692
という事は別ディレクトリで作成したqcow2を+Cした
ディレクトリに持って行ってもダメかな？
よーわからん。

移動では+Cは付かない
コピーでは付く
移動してファイル個別に付けても良いけど

6.1がdebian testingに降りてきたぜ

>>694
コピーね。ありがとう。
sparce=alwaysとかは必要ない？
何度もスマン。

pveをbtrfsのraid1でインストールしたら、2台のディスクに3つのパーティションができました。
raid1で動いているかどうか確認するコマンドってありますか？
filesystemはbtrfs fi dfで確認できるけどBIOS bootとEFI Systemが分かりませんでした

/dev/sda1 BIOS boot
/dev/sda2 EFI System
/dev/sda3 Linux filesystem

片方でPartition 1 does not start on physical sector boundary.が出てるので
いったんパーティション削除したいです(startが63でなく34なのが謎ですが)

mkfs.btrfs -m raid5 -d raid5
mkfs.btrfs -m raid1 -d raid5

どっちで作る方が良いのかな？
最初後者で作ったけれど考え直して前者で作り直した。
検証しなきゃ分からないだろうしそもそも発展途上なので先々どうなるかわからないもんな。

ファイルごとに変更履歴を自動で管理してくれて個別に戻したりできるファイルシステムってある？

nilfsならできそう

>>700
ありがとう
確認してみる

メタデータやデータベースみたいにランダムアクセスするデータをRAID-5に
書き込むのは効率が悪いぞ？

例えばストライプサイズが 256KB で４本構成の場合、768KB のデータは256KB毎に
分割されてドライブA,B,Cに、パリティ計算結果はドライブDに格納される。
この状態でランダムアクセスで4KBだけ書き換えるとどうなる？

768KB中400KB目～403KB目までの4KBだけ書き換える場合、書き換えるのは
ドライブBの144KB目～147KB目までだけじゃないぞ。
ドライブDのパリティ256KB分も書き換えなきゃダメ。 RAID-1なら8KBで済む。

下手するとこれで済まないのが RAID-5 の困ったところ。
パリティ計算する際には768KB分メモリに無いと計算できないわけで
それがメモリキャッシュ上に載ってない場合はパリティ計算する前にドライブA,B,C
から256KBずつ768KB読み込みが発生するのよ。

加えてデータベースの、特にトランザクションログやファイルシステムのメタデータ
はロールバックの関係上非同期書き込みではなく同期書き込みが要求
されるので、書き込みを開始して完了するまでの応答時間が長いRAID-5は
相性最悪なんだわ。

わざわざデータ領域とは別の RAID で格納できるように設計されてるのは
そのためってこった。

>>702 ありがとう。
もうガッツリ -m raid5 のにデータ移してさっきお古のHDD群を物理的に破壊してしまったよ。。

>> ドライブDのパリティ256KB分も書き換えなきゃダメ。 RAID-1なら8KBで済む。

いやあ言葉がないや。わざわざ -m raid1を作ったのに作り直したのは、
「きちんと理解していないのに直感だけで小賢しいことするのは辞めよう」
と思ってのことだが、今度からは教えて貰えるチャンスあるうちは待つは。

まだ7.5TB利用なので、別機の2x4TBをraid0にすれば引っ越し→再構築→データ戻しできる。
暫くは放置するので、追加のアドバイスがあれば教えて貰えると嬉しいです。

>>703
ググったらマウント状態でも btrfs balance コマンドでデータもメタデータも
プロファイル変換が可能ってでるね

安全をみてデータ引っ越しはしときます。やっぱ変換するのが良いと自分も思います

>>699
snapperではダメ？
管理は個別ではなく全体だけれど

btrfsのautodefragって効いてるのかどうか分かんない
新しく書いた所だけデフラグする？らしいけど
どれくらいデフラグされたか確かめる方法ある？

btrfsのRAID6はいつになったらまともになるんだ
いつまでたってもzfsから移行できないじゃん

手動デフラグしてみたら空き容量が減ってしまった
balanceとかやってみるも
完全には戻らず

共有されてるブロックが分離されるからそりゃそうよ

btrfs ムズくね
利用者少ないからかドキュメント限られてるし
hdd2台のrootfsをraid1で組んだ状態で試しに片方抜いたらブートがinitramfsで止まって手動でmountしようとするとuuidエラーになるし

片方死んでも稼働し続けられるのが売りなのにできないんじゃ意味ないじゃないかｗ

degraded付けてもだめ？

uuidエラーってことは設定が悪いのでは？

ルートにRAIDシステムを置くのは難しそう
対応しているOSに自動でやらせたほうが良いかもしれない
SUSEならbtrfsも対応してるかな

自分も最初は同じように思ってSuSE試したよ。（3年くらい前）
サブボリュームの多さに面食らったので運用でのルートbtrfs化は見送った。

今のSuSEは知らないけれど、当時は自分で勝手に、
ルートは枯れたext4、作業領域はbtrfs.snapperの1hスナップ、
書庫はbtrrs.raidが楽で便利だと判断したので、身の回り全部似たような構成で使ってる。

>>710
まじかー
もう失われた容量は戻らない？

>>717
Dedupe したら回復できると思う

便乗質問だけども、btrfsのdeduplicaterって標準では無くて外部ツールとしては複数あって迷う
おすすめないですか

>>719
https://github.com/Zygo/bees

>>720
サンクス

>>713
/etc/fstabにdegraded入れるだけだとだめみたい

>>714
raid1構成でbtfs filesystem showで見えるuuid(fstabにも記載済み)と片方HDD外してinitramfsで止まった時に表示されるuuidが違うのよ

>>715,>>716
PVE使おうとしてて、btrfs raid1でインストールすると/がraid1構成になるのよね

そうなんだ。
btrfs.raid1の/がデグレードで稼働しないのなら、
実際に試したことないから知らなかったけれど、想定外で驚くな。

念のため重ねて聞くけれど、
mount -o degraded /dev/sd? /mnt/point
やってもダメってことだよね？

>>723
こんな感じでした
�@initramfs起動した後にmountを打つと「none on / type rootfs (rw)」が表示されている
�A�@の後にmount /dev/sda3 /を打つとuuidエラーとなりmountで確認してもマウントされてない
�B�Aの後にmount -o degraded /dev/sda3 /を打つとUnknown parameterと言われ失敗しているように見える
�C�Bの後にmountを打つと�@の表示＋「/dev/sda3 on / type btrfs…」と表示されてマウントできてるように見える
�D�Cの後にcat /etc/fstabを見ても空ファイルで/がマウントされてないように見える
�Eexitでinitramfsを終了すると何か処理が走った文字列が表示され途中で止まる

>>724
>>マウントできてるように見える
こんなことになるんだな。ごめん僕には力になれない。

本当に余談だが、
自分は>>716の経緯でbtrfsを使い初めたので/のbtrfs化はしていない。
それでもkernelとbtrfs-progsは最新を追っている。まだ先駆的な技術だと思っているので。
自分らには/のbtrfs化はまだ早いのかも。とにかく力にはなれないがトラブル報告はありがとう。

https://www.phoronix.com/news/Linux-SSDFS-NVMe-ZNS-SSDs
SSDFSなるものが出たらしい

ＮＡＳに超〜〜〜長いファイル名を生成して何も出来なく成って焦った。
ドラッグ＆ドロップがダメ、ファイル名の修正もダメ、ツールもダメ。
コマンドプロンプトも「cd」はＵＮＣパスは設定出来ないからダメ。
ネットを検索したら光明が見えた。「pushd」というコマンドを使う。
このコマンドはＵＮＣパスでもＡドライブにするスゴイコマンド。
無事に自己解決できたでゴザル。ＦＡＱかもしれないが一応報告しとく。