ファイルシステム総合スレ その19
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>661
xfsって壊れやすいって本当?
なんかレガシな感じがして受け付けないんだよね。
そういやreiserfsはタイーホ後からどうなったのかね?
当時は先進的だったけど。 >>663
reiserfsは非推奨になってて2025年に削除される予定 ファイルサーバーにZFS使ってるけど安定してる
RAIDZ2組んでて一度HDDが一つ壊れたけど復旧も簡単だった ZFSはARCが重いんだよな
LRUよりは効率的だけど計算量が多いわ >>663
xfsはCOW導入で安定性が落ちたという話は聞いた気がするけど、その続報を聞かないな。話題になってないってことは安定したのか、皆避けてるのか 圧縮ファイルシステムでおすすめを教えて
主にテキストのログをどんどこ吐きたい btrfsかF2FSかな
ログ出力用途ならF2FSのほうが向いてそう 金持ってたらgpfs使いたいんだけどな
安定性は元々HPCやエンタプライズ向けだから折り紙付き
パスは255"文字"だしPOSIXで圧縮・暗号・ネットワーク共有・スナップショット・SSDキャッシュ等々
たいてい何でもあり、重複排除はあるのか知らんが 完璧ファイルシステムないよな
文房具みたいなもんでやりたいことがいろいろバラバラなんだろうな 当初から設計にも実装にも問題がなければ個人ユースでは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
どっちで作る方が良いのかな?
最初後者で作ったけれど考え直して前者で作り直した。
検証しなきゃ分からないだろうしそもそも発展途上なので先々どうなるかわからないもんな。 ファイルごとに変更履歴を自動で管理してくれて個別に戻したりできるファイルシステムってある? メタデータやデータベースみたいにランダムアクセスするデータをRAID-5に
書き込むのは効率が悪いぞ?
例えばストライプサイズが 256KB で4本構成の場合、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エラーになるし 片方死んでも稼働し続けられるのが売りなのにできないんじゃ意味ないじゃないかw ルートにRAIDシステムを置くのは難しそう
対応しているOSに自動でやらせたほうが良いかもしれない
SUSEならbtrfsも対応してるかな 自分も最初は同じように思ってSuSE試したよ。(3年くらい前)
サブボリュームの多さに面食らったので運用でのルートbtrfs化は見送った。
今のSuSEは知らないけれど、当時は自分で勝手に、
ルートは枯れたext4、作業領域はbtrfs.snapperの1hスナップ、
書庫はbtrrs.raidが楽で便利だと判断したので、身の回り全部似たような構成で使ってる。 >>710
まじかー
もう失われた容量は戻らない? 便乗質問だけども、btrfsのdeduplicaterって標準では無くて外部ツールとしては複数あって迷う
おすすめないですか >>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で確認してもマウントされてない
BAの後にmount -o degraded /dev/sda3 /を打つとUnknown parameterと言われ失敗しているように見える
CBの後にmountを打つと@の表示+「/dev/sda3 on / type btrfs…」と表示されてマウントできてるように見える
DCの後にcat /etc/fstabを見ても空ファイルで/がマウントされてないように見える
Eexitでinitramfsを終了すると何か処理が走った文字列が表示され途中で止まる >>724
>>マウントできてるように見える
こんなことになるんだな。ごめん僕には力になれない。
本当に余談だが、
自分は>>716の経緯でbtrfsを使い初めたので/のbtrfs化はしていない。
それでもkernelとbtrfs-progsは最新を追っている。まだ先駆的な技術だと思っているので。
自分らには/のbtrfs化はまだ早いのかも。とにかく力にはなれないがトラブル報告はありがとう。 NASに超〜〜〜長いファイル名を生成して何も出来なく成って焦った。
ドラッグ&ドロップがダメ、ファイル名の修正もダメ、ツールもダメ。
コマンドプロンプトも「cd」はUNCパスは設定出来ないからダメ。
ネットを検索したら光明が見えた。「pushd」というコマンドを使う。
このコマンドはUNCパスでもAドライブにするスゴイコマンド。
無事に自己解決できたでゴザル。FAQかもしれないが一応報告しとく。 コマンドプロンプト、UNCパスはダメでもネットワーク・ドライブに割り当てればコマンドプロンプトでcdできるのは有名だと思うが。
というか、cdにUNCパス食わせるとエラーでそう言われなかったっけ? >>727
ファイルをi-nodeで指定して扱う方法もあるよ。
大昔だけれど、日本語入力不可な接続環境で、
日本語のファイル|フォルダを扱いたくてこの板で相談して解決したことある。
全く関係ないけれど、
Linux板は年1回か2年に1回くらいしか自分はお世話にならなかったけれど、
たまたま前スレ見て何となく読んで書くのも何回かしてみて、ここは良いスレだわと思う。 ネットワーク・ドライブに割り当てればコマンドプロンプトでcdできるのはFAQ?
了解しました。我輩は初めて知ったでゴザル。ネット検索でヒットしなかったでゴザル。
ネットワーク・ドライブはルートの位置でしかマウント出来ないので不便でゴザル。
「pushd」ならNASの深い階層まで一気に指定してマウント出来るのでゴザル。 gio コマンドは?やったことないけどネットワーク利用 ござるござるよ須藤君は
ゆかいな味方 rootでござる rootでござる 外付けメディアをfstabに並べなくても/etc/udisks2/mount_options.confでデフォルトのマウントオプションを変えられることを今更知った
これでDOS/Windows系からファイルをコピーしてきたときに全部実行可能属性が付いちゃってるのを回避できる Improved Btrfs Scrub Code Readied For Linux 6.4, ~10% Faster
https://www.phoronix.com/news/Btrfs-Linux-6.4-Better-Scrub btrfsサブボリュームの削除が終わらない
これで進行状況見ると、1 orphans left to cleanとだけ出る
ちなみにHDD
Ubuntu Manpage: btrfs-orphan-cleaner-progress - show progress information about background deletion of
https://manpages.ubuntu.com/manpages/focal/en/man1/btrfs-orphan-cleaner-progress.1.html 0 orphans left to cleanになってもずっとbtrfs-cleanerが稼働中 BTRFS不具合多すぎるんよ
ドキュメントもほぼ役に立たないし
異容量でRAID1組めるだけに留めときゃいいのに >>737
Linux 6.1系と6.2系だけで起きるっぽい
カーネルを5.15系に戻したら起きなくなった
バグ? パターフェスで作成した ループバック イメージ 領域が壊れた
情報がなくて復旧は諦めた
ルプバック イメージで利用するのはあまり良くないのかな >>740
再現性あるなら、報告したら直してくれそう VM格納してる場合や書き込み多い場合nodatacowでマウントだよな? ZFS使ってる人いる?
用途どんな感じ?
優位性、どんなときに感じる? コマンドがわかりやすくて短くて簡単で使いやすいところ好き ZFS、proxmoxで暗号化mirrorで使ってる。
標準で暗号化、冗長化、snapshot、ファイルシステム(dataset)、ボリュームマネージャ(zvol)、CoW、全て一つで完結してるのが魅力。
メリット: 色々組合せる必要無くシンプル、柔軟な設定(ARC、L2arc、slog、special vdev)
(敢えてあげれば)デメリット: ライセンス問題、他よりマイナー、datasetの速度、CoWを外せない、かな。 追記: ZFSはdebian on OpenZFS。
少ないメモリ(とswap?)でHDDにWindows VMのディスクベンチなど短時間に大量の書込をしたらpanicしたことがある。
arcやtxg最大サイズを適切なものにするのがオススメ。
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-dirty-data-max-max >>744
Hackintoshで使ってるOpenZFS for macos2.1.6
一種のゲーム的な面白さがあるのよ
このフォルダはほぼ開かないから
圧縮設定強めにzstandard で高圧縮してコピーだとか
このデータベースだけSSDに多く食わせようとか
xp時代のHDD先頭パテ切ってキャッシュにしたりするような
あれの延長上的な攻略的なゲームに
macOSの整理整頓軽の面白さが混じってて面白い
Spotlight面白すぎる
special vdevでメタデータとSmall BlockをべつSSDにする方法はないのか 返答の御礼も書かなかったバチが当たったようです
メインでWindows機を使っていて、USBケースで海門6TB(NTFS)使っていました。
1週間ほど放置したらノートPCの電池が切れてNTFSが飛び、chkdsk /f /rも無駄に。 停電に見せかけたHDDの障害かもしれんんやで。
同じロットのHDD積んでいるんだろうな、と思われるものでマシンのが同時期に壊れるとか。 ある時からぶっ壊れ状態となったが電源を切るまでは動き続け、
電源を切ったら再始動できなくなるというのはHDDの障害としてはありがち。 大分昔の職場で大型連休の度に全PCの電源を落としていたが
連休明けとかに何回か再起動を繰り返さないと立ち上がらないHP-UXが近くの部署にあった
開発な癖にそんな危なっかしい機体を放置してる部署もどうかとは思ってはいたがそれはともかく
一回スピンアップに成功すると正常に使えるように見えるって奴とかな フリーソフトで、mp3の音楽ファイルが5つくらい復旧しました。
wmvファイルは、何故か全てが「信長の野望 戦国群雄伝 for Windows」からリッピングしたwmaファイルの断片群に化けていました…
chkdskなんて掛けないでUbuntuか何かのLive USBメモリで起動してマウントすべきだったのかも >>757
最後が違う。「マウント」しないのが正解。まず、OSを起動する前にBIOS/UEFIで問題のHDDが
表示されていれば認識しているので、Linuxを起動し、"/dev/sdX"とdevice fileとしてのみ
認識している(umountされた)状態で、以下の2つの方法を取ると、file復活の可能性が高まる。
・TestDisk (NTFSのMFT修復等のHDDの整合性修復。案外これで直ることも多い)
・GNU ddrescue (HDDの起動音から瀕死に近い場合。patition imageを別のdeviceに作成、
このimageをmountしてfile抽出を行う。物理破損がないHDDに多くの業者が取る方法がこれ) 突然の電源断に対してはchkdskはそこまでおかしい選択肢ではない
一方でWindowsのコマンドラインのchkdskは、最近はほぼ放置状態(MSが改良を試みていない)という説もある
>>753が指摘しているように、本当に「突然の電源断」なのかっていうところもある
普通はノートPCはバッテリーが切れそうになったら休止状態とかに入るものじゃないのか
なのにHDD破損に至ってるのは、最初にHDDが故障して、OSも停止してスリープや休止に入れなくなり、バッテリーを使い果たしたのではないか? chkdsk /f /r
の実行自体がダメだったのでしょうか
実行前にddrescue実行必須?? >>761
OSはm.2 SSDに入っていて、今も問題なく起動できています。
SEAGATE ST6000DM003をケースに入れてUSB接続したまま放置したらNTFSが死んでいて、Windows 11のディスク管理画面ではrawという認識となっていました。 >>762
マウントすると I/O Error 起こすセクタに当たった時にそこを読もうとして
延々エラーを繰り返すので I/O Error を読み飛ばす系の dd (ddrescue とか)
や chkdsk/fsck かが必要。
ddrescue は操作している間にディスクが完全にお亡くなりになるリスクへの対策。
今回の場合ディスクが完全お亡くなりになってない(ファイルが5個サルベージ
できた)ので ddrescue してもしなくても同じだった可能性が高い。
なので chkdsk は判断としては正解だった(chkdsk の前の段階で手の施しようが
なかったんだ)と思う(個人の感想です)。 単なる不意の電源断がその場であって
ダーティフラグ立ってるだけと確証があるなら
chkdskかける判断はおかしくないけど
大原則として論理的な障害ではなく物理障害が
少しでも疑わしいと思えたらその時点で
そのハードウェアに触れるのは
必要最低限に留めてかつ迅速に行うべきで
理想的にはddrescueなりで出来るだけ完全(に近い)複製を安全な場所に取ってから
そのイメージやらファイルやらだけを相手に作業をすべき
壊れたハードウェアの上でパーティション情報やファイルシステムの論理的なチェックや修正をかけても
まずその操作で余計に状況を悪化させてトドメ刺すだけだから少しでも疑わしければ安易にやっちゃいかん
ttps://wiki.archlinux.jp/index.php/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%AA%E3%82%AB%E3%83%90%E3%83%AA そこまでする価値のあるデータならそうするが、大抵の場合は本人が主張するほどに大事なデータではないんだよなぁという感慨しかない 今日は私の宝物をご紹介しましょう。将棋の駒。何の変哲もないように見えますけど実はここに血痕が付いてるんです。 >>766
そもそも壊れたストレージごとき相手に
奮闘してまでサルベージしないといけない時点で普段から予算も手間も割いてないのは明らかだからな
そこまで必死になるほど真に大事ならバックアップコピーでもRAIDミラーリングでも
なんでもいいから冗長化していて然るべきなわけでさ btrfs、破損とかは今のところ無いが
謎のフリーズの問題やディスク書き込み量の増加に悩まされた
ZFSに変えようかな RedHatが匙を投げたファイルシステムを使うんだからその辺りは覚悟すべき 100MBのファイルをcpする場合
本来なら100MBの書き込みが発生するけれど
COWできれば共有で100MBの書き込みが省略されるので
本来の書き込み量に比べて実際の書き込み量は減るという意味なのでは 変更されるまで実際には書き込まない
スナップショット的な動作を想定してるなら
CoWには限らない なるほど。そういえばreflinkオプションあったのを忘れてた。 btrfsはやっぱりなんかあるのかな。
突然あるディレクトリ配下だけが全部サイズ0になってアクセスできなくなった。
でも、rootだと普通にアクセスできたから、とりあえずは復旧できた。
なんか気持ちが悪いんよね。
圧縮とサブボリュームが便利で気に入っているんだけど。 Btrfsを使うならカーネルは常に新しくしておかなきゃね
古いカーネルでフォーマットしたBtrfsは不具合があるとかなんとか カーネルに変えた時古いカーネルでフォーマットしたものはどうすればいいの そのまま使えばいいんじゃない?
新しいカーネルなら過去の問題は適宜検出してwarning出してくれると思うので。 そんな便利機能はないぞ
データを待避して再フォーマットするのが無難 RAID6やZFS Z2がブッ壊れたときみたいらな Btrfsを使うなら
FedoraかUbuntuの非LTSかローリングリリース系のディストリのどれかを使いたいね
それ以外だとしたらカーネルだけ最新にするキメラしないと厳しい Linux カーネルならどのディストリビューションでも簡単に最新にできるだろ。
バニラカーネルでコンパイルエラーになる事無い気がする。 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で対抗だ ランダムに変な負荷かけたり
1秒間に1000回マウントとアンマウントを繰り返したりするんだろう多分
時代はBtrfsなのにやってられんよな スタックトレースで分類したら実質数個じゃないのかね ファジングテストの事でしょ…と思ったが多少違うっぽいな
AIが生成しまくるコーナーケースのバグレポートに疲弊したって話っぽい
まぁXFSは赤帽の生命線なんだから問題起きても赤帽がなんとかしてくれるんじゃない? >>803
なんかJFSがいいよ、っという神の声が聞こえた気がした。
ext4 と比較して利点も欠点もないはずたが、Linux での採用例が少ないという大きな欠点。 >>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なんだよな >>810
そう考えるとRHは凄いんだな、と思いました。 Btrfsは事実上facebookがメンテしてるからね
自社でメンテしてるファイルシステムだから採用しやすい >>812
オワコンというよりいい具合に枯れきった
ファイルシステムになった感じ
先進性より安定性が必要な用途でお呼びがかかる
老兵っぽいイメージ もちろん頼もしいのが第一だが、
逆に言えば現メタ(だけじゃないが)の使用してるユースケースに沿わない使い方に関しては中々進歩しないのが弱点だと思う
RAID56が長い間ダメダメだったのやFS単品での暗号化や階層キャッシュが望めないのもDCでbtrfs使ってる処がそういう機能に興味もってないからだろうし RAID5/6 でのバグは直ったのか?
家庭用では無い構成だから関係ないと思ってはいたけど。 治るもクソも根本的なライトホール問題があって、ディスク追加の扱いが悪い意味で柔軟なBtrfsは対処が難しいからメンテ側が乗り気じゃないって話じゃないかな
現状は最新カーネルかつメタデータのraid構成を別にすれば良いけど実績も脳死で使える安心感も皆無だし
とはいえ主流のハードウェアraidはデータ化けに弱いんだからチェックサム有りfsで安心して使えるraidがもっと一般化してほしいお気持ちもある Btrfsのディスク構成の緩さは異常。なんでもかんでもストレージプールに合体できる 自分はbtrfs嫌いじゃないから不満はないがSSD最適化とか将来的なZonedStorage対応考えるとほかに選択肢なくなっていきそうなのは真剣にどうかと思う ストレージプール使うと遅くならない?
5400rpm のHDDが悪いのかもしれんし、比較で測定もしてないけど。 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を細々とメンテするだけじゃないかな。 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とディストリで気軽に使えてプロ相手にも十分通用する暗号化ってなんだろう・・・ >>851
スナップショットのあるファイルシステムいいよ
いつでも全ファイルの差分が見えるし、バックアップ取るときもまずスナップショットを取ってそっちを対象にすれば
メインボリューム側では整合性期にせず作業続けられるし >>855
Fedoraのデフォルトになって数年が経過しているから安心していいよ Btrfsの透過圧縮でわざわざ標準外のレベル設定するのってだいぶ特殊用途なんでは…? Fedoraチームがベンチマークを取ってzstd:1がベストと導き出したんだよ 5年以上 zstd で btrfs使ってたけど自分は問題無かった。
今はZFSでzstd使ってるけどこっちも問題ないよ。 >>860
btrfsからzfsにした理由とかある? 純粋なストレージプールが欲しいならzfsやcephあたりで良いんだろうが
仮想化ゲストならvirtiofsが主流になって使いやすくなってほしいなぁ 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だったら中がぐちゃぐちゃでもそれ片付ければ済むんだよ
焼くこともできない惨状 もはやBtrfs以外は使わない理由を説明する必要があるレベル zstd:1で圧縮して時々スナップショットを取る使い方が標準だよ
バックアップを一瞬で取れるから派手にファイルを扱える >>874
いうても同じボリュームにスナップショット取ってるんやろ? スナップショットとバージョン管理は根本的に似てるような気もする
gitとbtrfsで何かfusionできないかな 言われてみると rsybc の差分バックアップで間に合うような気もする 俺は2005年くらいから毎日差分バックアップしたhomeディレクトリがある
当初はpdumpfsで途中からrsyncを使ってとったもの
つまりファイルに差分がなかったらハードリンクにして容量増加が抑えられる
ファイルとかハードリンクとかは当時から何も変わらないからまだ使えるんだけど
その下のストレージもfilesystemも開始した当時とは全く変わってしまった 普通の差分バックアップとBtrfsなどのスナップショットの違いは
ゴミ箱に放り込んだ後の挙動だね。
普通の差分バックアップは一応次のバックアップまでは容量が回復するけど
Btrfsのスナップショットだと、一度でもバックアップをすると
以降はファイル削除で逆に空き容量が減ったりという奇怪な挙動になる。 スナップショットそのものをバックアップとして運用するんじゃなくて
スナップショットで瞬間を固定したものを別の物理ドライブにバックアップするんやで
使用中のデータをバックアップするよりも整合性の心配をしなくてよくなる >>882
それ、スナップショットを別の物理ドライブに取ればええんでないの? 昔使ってたストレージを思い出した。
データベース停止→同期ディスク切り離し→データベース起動→切り離したディスクからバックアップ→ディスク同期
データベース停止から起動まで5分だけど、バックアップは10時間とか。 スナップショットはバックアップではないと何度言えば解るのか スナップショットも全部別ボリュームにバックアップや 俺はスナップショットを使ったことないんだけど
スナップショットってある時点のファイルシステムの状態を
保存できるというので良いのかな?
スナップショットってのは何回も取れると思うんだけど
するとこれらをバックアップしようと思ったら
他のストレージに複製する必要がある
それはフィルシステム階層でやるのかな? 複製されるのはフィルシステムのイメージ?
それともその上のcpコマンドとかrsyncでファイルとして複製するのかな? 物理的な破損に対する対策をしたいのかデータ的な破損に対する対策がした以下によるでしょ。
よほどのことがない限りは通常利用でSSDが物理的に破損するなんて無いからスナップショットで十分だよ。 >>892
>SSDが物理的に破損するなんて無い
そなの? 熱で歪んではんだクラックすることはあるよ
基板を使った全ての電子機器に言えることだけど >>892
物理的な破損じゃなくてもコントローラーのバグでデータ消失とかあるだろ。SanDiskとか。
バックアップは物理的に分けるのが基本。 >それともその上のcpコマンドとかrsyncでファイルとして複製するのかな?
そうだよ、スナップショットをマウントして、ファイルを「別の場所に」コピーしてはじめて正当なバックアップと言える。
これらの手順を簡略化できるsend/recvコマンドが用意されていて、
こっちの方が効率いいし、メタデータも丸ごとクローンできる。 >>896
>そうだよ、スナップショットをマウントして、
なるほどね
俺はrsyncで良いや
夜中に寝てる間にやるから問題なし /をスナップショット撮ってその領域を別筐体にrsync or cpし、ブートローダー入れれば普通に動くものですか?
やはりddが必要ですか? /var以下とか書き込み途中のファイルがあるだろうから
そこは影響あるかもしれんが多分大丈夫でしょ Debianは単なるマウントポイントで起動ディスクを指定してるから動く。
FedoraはUUIDで起動ディスクを指定してるから動かない。 SSDはHDDより気楽にセルが死んで内部のECCで誤魔化すつくりだから大手のちゃんとした奴でも壊れないって発想は絶対できないなあ
まあ結局は本人がどれくらいの信頼性とデータの保全を重視してるかだけど SSDは電気的に壊れたりしそうだしHDDより信頼していいとも思えない HDDのような故障の予兆はネエと思った方がイイですぬ マジで重要なデータならHDDはデータ復旧業者に持ち込めばほぼデータ救える
SSDは難しそう >>900
DebianだってUUIDで指定してるぞ fstabの指定じゃない?
sda,sdbとかデバイス名使うと順序が保証されないからいかんよ >>899
ありがとうございます!
明日試してみます! >>897
KVMとかで何十GBのイメージ(常時書き込みあり)を扱ってるんだけど、rsyncで不整合起きないものかね?
怪しいと思ってrsync(rsnapshotだけど)の対象にはしてなくて、イメージの中身のファイルをrsyncしてるけど。 >>908
fstabじゃなくてカーネルの起動オプション(cmdline)とinitramfsじゃないの?トラブるとめんどい。 cpした後chrootしてinitramfs作り直したら駄目なの? >>910
チェックサム確認して更新するオプションあるけど、そういうのはrsyncに合わない。
あくまで個々のファイル単位でのコピー。
また、チェックサム確認つけるとサイズが大きいファイルはコピーにその分時間かかる。 メインで使うLinux端末なりサーバなりはxfs+LVM
バックアップ用ストレージをbtrfsの構成にして物理的に分ければストレージ側で好きにバックアップ取れば良い
または仮想環境ならNAS上に仮想ボリュームがあるだろうからNASのバックアップ機能に任せる 複雑なことしてないけど、自分はこのやり方でdisk移行したことあるよ。
ttps://wiki.archlinux.org/title/Rsync#Full_system_backup >>915
/varの下は特に用量が大きいから、何箇所かは除外したいな。 >>912
/etc/fstab のUUID書き換えた後に (chroot 不要かも?) grub2-mkconfig かな。
書き換えが必要なのは fstab と grub.cnf (もしくはgrubenv) だ。
LVM ありなら initramfs 再作成も必要だったかも。 USB+cryptsetup(x3)をbtrfsでraid0にしてですな
使ってるうちにcsumエラーが出るようになるけどmd5sumは正常
カーネル4系だけどもう6出てるの? いまだにラズパイがbtrfsに標準対応しない理由が全然わからない そもそもラズパイはストレージがmicroSD/emmc前提で
SDカード内部のコントローラは基本的にfat等しか想定しておらず安物でSSD最適化が入りまくったbtrfs使うと不安定になりやすいしCOWの性能的なデメリットもバカにならない
ラズパイ6か7が出てNVMe標準搭載してから高級なFSのプリインストール願えばいいんじゃないかね csum error、dm-crypt + btrfs raid1 で出たことある。
用途はqemuのcache none で↓に引っかかっていた様だった。
ttps://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Gotchas.html#Direct_IO_and_CRCs 918です
一個がno medium foundになりまして生来ブキッチョでして壊したのでしょうか
oldoldstable(4系)からbookworm(6系)にアプデしたらなんかsyncが激遅くなった\(^o^)/ 自分なら怪しそうな動きをしているならまっさらの新しいストレージとファイルシステム用意して構築しなおすかなあ
データロストは怖い >>923
単に物理的に壊れかけてたのがいよいよぶっ壊れただけじゃないの?
カーネル上げた/ソフトウェアの不具合で no medium found になるとは思えないんだが...
あと raid0 でドライブ1つ死んでも sync できちゃうものなの?
その状態でマウントが read-only に落ちないのは不具合ではあると思うんだが。 BcachefsがやっとLinuxにマージされたぞ btrfs遅いって言われてたけどアップデートのペースが凄くてどんどん速くなってるからな
btrfsが使えるならそれでいいんだよ btrfs早くdfコマンドとか対応してくれ。
CoWだと無理なんかな? 今のBtrfsは開発が活発で安心感すらある
RAID56のバグもいよいよ修正作業が本格化したようだし bcachefsはビルトインで暗号化や階層キャッシュ出来るのが明確な強みなんだから言われてるほどbtrfsと競合しない筈なんだよな〜
ただ実績無いし長期的な開発体制も怪しいからまじで先が読めない
一方btrfsもRAID5,6に関してはライトホール問題はどうしようもないんだから長い長い道のりになる気がするな Microsoft の Dev Drive もちょい気になる bcachefsも追従してきたということはサブボリュームをディレクトリ扱いするのはそこまで利点あるのだろうか
zfs他のようにパーティション扱いで、加えてスワップファイルやVMイメージ用にスナップショット対象外フラグでも設ければ充分な気がするけども bcachefs のベンチマーク記事、bcachefsは bcache ベースで堅牢性と信頼性重視、とされてるから、速度なら低速デバイス+キャッシュ(dm-cache、L2ARC、bcacheなど)同士の比較が欲しかった。 >>936
本格的なベンチマークは6.7カーネルのリリースまで待つしかないんじゃないかな
喜び勇んで自分でビルドしてベンチマークしようとしたPhoronixで悲惨な結果になってるし
実際にZFSを置き換えられるのか等運用や評判の話は良くも悪くももっと後だろう fscryptかあ…dm-cryptの方が好みかなあ
ただ現状btrfs raid dmcrypt automountの連携に難ありというか…正しく調整するにはudevまでいじる必要があるのが面倒 ファイル暗号化だとシステムはTPMで暗号化して(起動時のパスワード入力不要)
ホームディレクトリはログインパスワードで暗号化といった使い分けしやすいのが利点らしい。
ユーザーが大量にいるケースでも個別のフレーズで暗号化出来る。
同じことを他の方式で実現するのは現実的ではない。 予行練習で試しにext4のfscryptを使ってみたけどめっちゃ便利だなこれ
ログインしていないユーザーのhomeフォルダは暗号化されたままだからdm-cryptよりも安心感がある
ほぼ起動したままだったから全体の暗号化にあまり意味を感じてなかったし Fedoraはfscryptによる暗号化をインストール時のオプションとして提供する計画みたいだね
xfsからbtrfsに乗り換えたディストリの強みを活かしていく ブロックグループの導入でマウントが遅い問題も解決されたし
Btrfsは最強のファイルシステムへの道を着実に歩んでいるな bitlot防止機能が素晴らしい
なぜ窓と林檎はbitlot防止できないんだい? マジレスするところなのかボケるところなのかわからんけどbitrotのtypoじゃない?
どう優れてんのか知らんけど bit rotという言葉は初見だったので勉強になりました。
ありがとうございます。
bit rot防止 login:Penguin 圧縮って使わないほうがいいかも
CPUが100%張り付いてる状況だとめっちゃ低速化する CPUが100%に張り付くようなマシンスペックが問題ってだけ
圧縮や重複排除はコアとメモリに余裕がないマシンでは使えねーのは
今も昔も変わらん ソースベースディストリで作業ディレクトリをcompressオプションでマウントとか? 結局Btrfsはやめてext4に乗り換えた
Btrfs自体は安定してくれてるんだけど
たまにext4に決め打ちされてる古いプログラムを踏んで不具合が出るのがキツかった >>921
信頼性が低いSDカードだからこそ
cowの堅牢性やチェックサムでデータ化けを検出できるのは頼もしい
ただ確かに普通のSDカードをシステムやスワップに使うと長時間のランダムライトについてこれずに激遅になるので
ハイエンデュランスのSDカードを選ぶ必要がある Linuxはbcacheを使ってssd+hddの階層キャッシュを簡単に組めるのは良いな
カーネルの標準機能だから起動や互換性のトラブルはまず起きないし。
Windowsはサードパーティのソフトに頼る必要があるし、
どれもデータ破損などのトラブルの報告がある bcacheって意味あるのかな?
良く分かってないのだけど
もっと高速なRAMにキャッシュされるので
RAMをたくさん積んどけば良いんでない? 一生懸命作っているから文句を言いにくいというだけで実用面ではBtrfsが安定した今としては必要ないね >>958
すみませんBtrfsってbcacheと関係あるんですか?
名前は似てるけども >>959
958じゃないけど、無関係だね。btrfsとbcache bcache使うなら kernel は LTS が良いかも。過去にやらかしがあったらしいので。 bcacheは大容量データを扱う機会の多いWindowsでこそ欲しいよね
>>958
bcacheとbcachefsは別物
紛らわしい名付けしたものだ 作者同じだし似たような技術使ってるから似た名前になってるんだが カーネルの標準機能だからトラブルはまず起きない、ってことはないんじゃないかな?と思った
カーネルの実装には問題なくてもユーザーランドのコマンドのバグで破壊とかないとはいえないし カーネルモジュールはコンパイルしなくてもいいんやで 一つだけWindowsがLinuxより優れている点がある
デフラグソフトが充実していて配置方法を選べることも多く
適切に使うことで再断片化を緩和できる Linuxは断片化が起きる前提にファイルを配置していくからデフラグの意味がないんだよ
だからデフラグソフトが無い デフラグせんでも別ストレージにコピーすればいいのだ vfatがデフラグ必要なのって毎回再配置しないので性能を稼ぐ意味合いだよね >>971
いらない
HDDでもSMRならデフラグしないほうがいい Linuxのfsもエクステント、b木の最適化くらいはどこかでやってるよね RAID-Z3みたいな機能をbtrfsが備えてくれればいいんだが… Btrfs Enjoys Performance Optimizations With Linux 6.9
https://www.phoronix.com/news/Btrfs-Linux-6.9 良いよ。
大半のパフォーマンスはext4が一番良いくらい。
xfs はファイル数などの上限が上がるので企業みたいな使い方をするならよい選択。
btrfs はCoW で条件によりコピーが速かったりファイルシステムを圧縮したり、高機能だし色々出来るけども、使い方を調べないといかん。 昔xfsでファイル削除が激重だったけど、何年か前に改善されたらしい 日本語版wikipediaによると
2020年 仮釈放の審査に落ち、2022年に予定されていた仮釈放がさらに伸びた。
2027年 仮釈放の予定
刑期短縮の為模範囚を演じてるだけじゃないかと思う 自分のプロダクトに自分の名前を付けるやつはやべぇ奴の法則 たしかに、リーナスは自分の名前を取ってgitを作ったからな バックアップ取らない派なので先日ext4のディレクトリをrmコマンド打つの間違って全部消して
結局復活できなかった
extundeleteもext4magicも結局だめだわ
btrfsはどこまで削除したやつを戻せるかわからんけどこれを期にもうこの際まず/homeをbtrfsに変えてみた
お、なんか動きは良い感じノードサイズは32kでやってみた
dmesgで「BTRFS info (device sda4): enabling ssd optimizations」なんて出てるのでSSD使ってる
からなんか良さげw
不具合なければファイルシステムはこれでいくかも >>980
あったね、10年ちょっと前にxfsにしてた。/も/homeも。要するに全部xfs
大きなファイルやディレクトリをrmすると重い
しかもこの頃のlinuxってIOの割り込みとかで結構へんな処理待ちが出る感じだった
IOの割り込み処理待ちでほぼ固まってる感じに近かったw
それはxfsだけじゃなくext3等も状況により処理待ちですごかったけどxfsはホント固まる感じだったね
今は本当に割り込みの処理待ちとかほぼ感じさせないカーネルになったんだね
ファイルシステムは実はその頃ReiserFSを使ってた時も有り、これは本当に速かった
開発者逮捕て使うの辞めたけどある意味逮捕なきゃ凄く良かったファイルシステムだったと思う
陰謀かなにかではめられて逮捕?
とりあえず暫くbtrfsかな。あ、電源バチバチ切ったりしてもなんだかんだ強かったのはntfsですね btrfsだいぶ枯れてきたよな
zfsから引っ越してまた1年ちょっとだが今のところド安定だわ レス数が950を超えています。1000を超えると書き込みができなくなります。