ファイルシステム総合スレ その19
ハンスが再来年出所する予定らしいけどreiser4が取り込まれることはありますか? >>183 15年でext4が進化し、より先進的なZFSやbtrfsの開発が進んでいるから 今さら感 でもZFSがメインラインに入る可能性はゼロだしRedhatはbtrfsやめちゃったし15年経ってもこれだっていうFSは無いね 現状見てる感じなんだかんだでRedHatにbtrfsが凱旋したりして Linux 5.12 Lands Fix For File-System Corruption Caused By Swapfile Issue www.phoronix.com/scan.php?page=news_item&px=Linux-5.12-Corruption-Fixed スワップファイルへの書き込みがスワップファイルを置いているパーティションへの書き込みになるバグ 5.12はまだまだβ版だからバグあっても一般ユーザーは気にせずOK xfs は!? ext4 は HDD によくて xfs は SSD にいいってのを信じて使ってるんだけど >>190 むしろ逆のイメージ。REGZA HDDレコーダーにXFSが採用された実績から大容量(TBクラス)ストレージ向けかと 現状ではXFSとext4でできることに大差はないから、rootにあえてXFSを採用することはないと思う SSDに良いFSで性能など実績があるのはF2FSのイメージが強い 俺もついさっきrootfsをf2fsでフォーマットし直したところだよ grubのバージョンがf2fsに対応してなかったから systemd-boot入れ直す必要があったけど (/bootを分けるのはUEFIな今の時代なんか嫌) Btrfs Will Finally "Strongly Discourage" You When Creating RAID5 / RAID6 Arrays https://www.phoronix.com/scan.php?page=news_item& ;px=Btrfs-Warning-RAID5-RAID6 むしろ今まで警告なかった方が不思議 カーネルに取り込まれたネイティブexFATはまだ使わないほうが良いぞ ・数GBに1〜2クラスタの頻度で書き込んだデータが破損する ・タイムスタンプのロケールの処理が正しくなく、Windowsとやり取りすると数時間ずれる ・Windowsでマウントするときエラーを検出することがあった ・去年ここで書いた、メタデータを更新するとタイムスタンプが破壊されるバグは直ってる ・性能はFUSE版よりかなり良い kernel 5.8 今はデフォルトで有効になってるからブラックリストで無効化する必要がある まともに使うなら 未だにxfsとext4の二択だよね実質。 >>193 確かに。警告無かったことを知らなかったわ Debian11からいよいよBtrfsに乗り換えてもいいですか? reiser4一択 ちょっとバラ肉にしたぐらいで開発者収監しすぎなんだよなあ NTFSはそこそこ優秀かも知れんが 管理するOSがWindowsではちょっとマンセーは無理 Windowsは互換性に関してはマジで凄い Linuxで10年前のソフトを最新環境で動かそうとすると苦労するからね Linuxはソースあるからね emacs(1976年)もTeX(1978年)も現役 ed (1970年代前半) も sed(1973年) も一応現役 sed は一応でなくて、シェルスクリプトの一部のように使うだろ。 そりゃそうか 俺も使うし それも結構な頻度で愛用している スレでもたまに名前が上がってたBcachefsって目的はすごい良いな、Btrfsが躓いてるからちょっと期待しちゃう Bcachefs は、 Btrfs と ZFS の機能をよりクリーンなコードベース、より安定性、より高速、 GPL 互換のライセンスを提供することを目的とした次世代の CoW ファイルシステムです。 Bcachefs一時期毎月20ドル支援してたんだけど、Btrfsが良い感じになって来たので、支援止めちゃった 目指すだけならどこも凄い事を主張するからなあ・・・ 速くする方法が分れば、他のファイルシステムも続くから頑張って欲しいな。 カーネル5.13でzstd関連のコードが刷新されるから 圧縮使ってる人は楽しみな更新になるね Bcachefsの公式ページを読んだら コードが綺麗ばかり主張していて、実際githubを覗いてみたら 確かに綺麗なのかもしれないけどコメントが少なすぎて誰も触れない事には変わりない感じだった。 $ sudo btrfs sub snap @ /media/user/debian/@ $ sudo btrfs sub snap @home /media/user/debian/@home このコマンドの参考ページを教えて下さい debianスレにも書いたんですが、ext5って開発されていないんですか? ということはいずれどこも(debianも)btrfsかxfsになるんですか? ちょっとお聞きしたいのですが、新規に買ってきた4TBの東芝製HDD(MN08ADA)をmkfs.ext4でフォーマットしてマウント(USB-HDDケースに入れています)すると、 何もファイル操作をしていないにもかかわらず頻繁にアクセスするのですが、(umountするとアクセスしなくなります)、 -O ^metadata_csumとしてフォーマットするとアクセスしないのですが、一体何が起きているのでしょう? USB-HDDケースが行けないと思って内蔵SATAにしてみても動作は同じでした。 試しに最初の300MiBだけフォーマットしてマウントしてみたらしばらくアクセスした後、静かになりました。 metadata_csumの有り無しで変わるのですから、ココらへんがおそらく原因だとは思うのですが、4TB分チェックが何かが終わるまで待つしかないのでしょうか? 自己解決しました。おそらくext4lazyinitだと思います。 もうしばらく放置しておこうと思います。 ntfs、btrfsでは何も起きなかったのでハードウェアの故障はないと思っていたのですがやっぱりext4の機能でした。 どうも失礼しました。 完全にBtrfsブームが来ているな FedraチームFacebookの全面バックアップは心強い Btrfsのスワップファイルを使おうとしたけど 素で使うとスナップショット出来ない代わりに生データだし 暗号化スワップとして使うと今度はスナップショット可能になるという理不尽 そりゃFedoraも匙投げてスワップ自体を無効化しますわ BtrfsにLVMを組み合わせてスワップパーティションを作るというダサい方法しかないし 変なことしないで普通にスワップパーティション切れば良いだけでは? >>229 やっぱりそうなるよね Btrfsは消去する可能性のあるデータの扱いに絶望的に向いてない。 >>228 サブボリュームが便利だったから スワップ問題さえなければBtrfsで大半賄えたから惜しかった。 >>230 > Btrfsは消去する可能性のあるデータの扱いに絶望的に向いてない。 うちは1年近くほぼ24h稼働させててビクともしないけどな ラズパイでUSBx2+SDのストライピングと言うなんちゃってだけどさ 俺も4年近くBtrfsファイルサーバ運用してて、btrfs deviceコマンド使って何度もストレージ構成変更もしたけど、何も問題起こらないなぁ。 エンタープライズとかでは無いけどね 消去する可能性のあるデータはCoW有効だと断片化が進むからな ここ1年くらい半導体不足だから難しいけどスワップが要るくらいならメモリもっと積むという手もある 最近はbtrfsも徐々に、使えるものになってきているのは確かだろう 職場で使われている「法人向けNAS」として販売されている製品がデータ領域デフォルトでbtrfsになってて当初はオイオイ大丈夫かと思ってたけど 今のところは大丈夫っぽい。ちなみに壊れても対処するのは俺じゃない(重要) あとは、ディスクフルになるとヤバいなどという噂もあったが改善したのだろうかね。 いやスナップショットとCoWの関係で 削除できてるんだか出来てないんだか分かりにくいという意味ね。 CoW無効化したファイルでもスナップショットは取れるみたいだし 削除という方向では難しい。 >>233 CoWは前述の理由でファイルを削除したら逆に空き容量が減るパターンがあるから ディスクフルだと危険だよ。 空き容量を増やそうとした操作で更に空き容量を減らしてドツボにはまる。 >>233 > ディスクフルになるとヤバいなどという噂 友人のラズパイ(うちのサブボリュームを暖簾分けしたもの)は diskfullをやらかして起動不能になり涙で枕を濡らしてますた スナップショットをという扱うという決断をした瞬間から Btrfsの空き容量を増やす手順は複雑怪奇になる。 timeshift使うくらいならまだいいけど 色々と欲を出すと悲惨な目に遭いそう なお私はconky出して常にディスク使用量を監視してます そんなこと無いけどなあ スナップショット全部始末して、それでも駄目ならfilesystem defrag -r これで容量が戻らなかった事無いけど スナップショット全部始末って・・・ まあ戻らないことはないだろうけどさぁ・・・ それデータ退避させて再フォーマットに次ぐ最終手段やん 俺の場合スナップショットはシステム改変前の保険や send前の準備くらいにしか使ってないからねえ もっと高度な事やってる人なら億劫だろうけど それ正解。 非常に賢いBtrfsのお手本のような使い方。 スナップショットをバックアップのように使ってるのが間違いなのよ バックアップは別に取ってスナップショットは定期的に整理すべき マウントしたまま完全なdumpが出来る様な感じですからね >>247-248 スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの? Btrfs はサブボリュームとかのメタ情報のバックアップができなくてバックアップが困難 と逆に感じたんだが >>249 > スナップショットを tar で固めるだけだったら別に取りやすいって事は無いんじゃないの? send/receive機能使った事無いのかな > Btrfs はサブボリュームとかのメタ情報のバックアップができなくて その様な些細な情報に拘るよりも サブボリュームをリネームしておけば管理しやすいのに そこまで完ぺきな状態保存をしたいならddでも使っときましょうかね >>250 > send/receive機能使った事無いのかな なるほど増分バックアップを取るという意味では dump に近い物があるのか 勉強になりました > その様な些細な情報 メタ情報バックアップできないっておかしくない? 別の誰かが作ったシステムをクローンしたい時に dd しかないのは厳しいわ ビジネスでやったらバックアップできないシステムを採用するのがおかしいって 後でぐじぐじ言われまくる(=言い訳レポートだの再発防止だの工数が爆発的に 増える)のが見えてるんで使えないよ 考えた方が違うんじゃないかな。 サブボリュームをほぼストレージとして見れば問題ないし、完全なコピーが欲しければddなりなんなり旧来の方法が取れないわけでもないし。 単にレイヤーと選択肢が増えただけだよ Btrfsを本番で運用しているFacebookはどうしてるんだろうね Btrfsでdiscard=asyncにしたら起動するたびにドライブの使用ランプがカリカリ始めたんだけど これって他の人も同じ? カーネル5.14でbtrfsが更に改良・高速化されるらしい 開発ラッシュやばい もうBtrfsで良さそうだね ネイティブ暗号化くらいしか弱点ないでしょ RAIDはHBAかLVM使えばええやろ ファイルシステムがやらなければいけないことではない スナップショット使うファイルシステムでHBAやLVMでのRAID-5/6はやめとけ スナップショットはランダムリード/ライト多いから相性が悪い 使っているうちにフラグメンテーションで使い物にならなくなる 回避するためにはHBA使うのやめてRAID-Zだのそれに類似したVirtual系 RAIDの技術が必要なんだが実装ツラい割に効果も薄いんだろ ラックマウントタイプのストレージ製品でもRAID-10でしか使わせない製品も 出始めてるし、業界としてRAID-5/6は切り捨てなんだとおもう ファイルシステムによらず、RAID5はテラバイト級媒体にはそもそも使わない方が良い 障害復旧中に壊れていくのを数回見た RAID6は知らない RAIDZは広く使われてるよ RAIDはストレージの可用性確保の手段なんだから代替方法なんかない RAID関連は実績のあるファイルシステムでないと使う気にはならない ファイルシステムの実績もだけどパーツ冗長(特にコントローラ)も必要だわ HBAが中途半端に故障して壊れてもないHDDを故障扱いしまくってデータ ロストさせた(実際はデータロストしてない)障害が一番厄介なトラブルだった 一般ユーザーがしないような構成を組むと 想像もしていなかったような不具合踏むことが多々あるわな Btrfsはdiscardマウントオプションでまだ壊れた報告がチラホラあるね とりあえず手動trimに切り替えた Linux 5.14 Works Around Compatibility With Some Digital Camera exFAT File-Systems www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-exFAT Linux上で以前targetcliで作ったZVOL (/dev/zvol/mypool/fc0) が「使用中」状態に なったままになってます。再起動してもOSを再インストールしても「使用中」状態です。 # zfs destroy mypool/fc0 cannot destroy 'mypool/fc0': dataset is busy # umount /dev/zvol/mypool/fc0 umount: /dev/zvol/mypool/fc0: not mounted. 未使用の状態かそれが無理なら強制削除したいんですがどうしたらいいでしょうか? >>270 解決しました。理由はイニシエータ側で作ったLVMをターゲット側が起動時に 自分のものとしていたため。 exFATがDebian11でサポートされるようになったらしいね Debian newsにそう書いてあった うーん、ZFSはイマイチですね・・・。 Proxmoxで3*HDDをRAIDZ1にして、2*SATA SSDをキャッシュにしてVMを作ったのですが、 前情報通りアクセスが増えるとメモリ消費量が10GBとか跳ね上がる・・・。 1200Mb/s出ていたものがカーネルパニック?で20Mb/sとかに落ち込んでしまう。 2GBのファイルをランダムコピーしたら、一瞬で終わるものと数十秒かかるものが発生。 うーん、ZFSはかなりじゃじゃ馬な印象です。メモリが潤沢にあれば良いのかも。 やはり記憶域スペースですかね・・・・。 確かに自分もデスクトップ用途で多目的に利用しているんだがバター FS の方が適してると考えるようになってきた 今度、Debian11 インストールしようと思うが、Btrfs でいいのか。 コピーオンライトをファイル単位でユーザーが使えるのはバター FS だった OpenZFS2.1で実装されたdRAIDってどうなの 再構築が高速なのは良いことだけど、その後新しいホットスペアを追加したら結局再構成が始まるんでは? RAID-Z2と何が違うんだろ openzfs-2.1.0 kernel-5.13 fedora34 ZFSで例えば2つのプールpool1, pool2 があるとして,ブート時にpool1は自動で インポートしたいけどpool2はしたくない場合,どうすればいいですか? <(_ _)> >>278 いましがた dRAID の説明を初めて読んできた初心者なので参考まで > その後新しいホットスペアを追加したら結局再構成が始まるんでは? 語弊がある書き方をするけど再構築が高速になるトレードオフとしてホットスペア にデータを事前にデータを書き込んでおく(準備しておく)ってだけじゃん リビルド中に2本目と3本目が相次いで壊れてデータロストするリスクを(リビルドを 高速化することで)回避するためのものだから効率が悪い・二度手間な処理を行う のは至極まっとうな話では? > dRAIDってどうなの 全てのディスクを均等に使用してしまうことによって HDD/SSD の故障時期が重な る可能性が高まるという点で逆にリスクを上げてるアホな仕組みだと思った 商用の FS (NetApp や Isilon, Spectrum Scale FS) において同じ仕組みは個人的 には聞いたことが無いので期待できない > RAID-Z2と何が違うんだろ いや、RAID-Z や RAID-Z2 に対してホットスペアをどうするかのオプションだから 違うとかじゃなくて「dRAID 構成の RAID-Z2」とか「dRAID 構成ではない RAID-Z2」 とかそんな感じで別物ではないぞ? >>280 RAID-Z2 と RAID-Z+dRAIDホットスペア1本はほぼ一緒では?と言いたかった。 ホットスペア本数に制限がないので、冗長度を好きなだけ上げられてかつread性能も上がるのが利点なのかな? 商用はIBMが既にやってるらしいけどね。 RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた RAID再構築はパリティ再計算のために、生き残ったドライブの全データを読み込む必要がある?が dRAIDは追加スペア分の空き容量を生き残ったドライブに分配するだけなので、生き残りがn本なら各ドライブ1/(n+1)のデータだけ読めばよい? あとパリティ計算がいらない。 あれ?割と良いのでは? >>282 > RAID再構築とdRAIDのホットスペア追加の違いをもう少し考えてみた 流石に比較が間違ってるだろ、それ RAID-Z + ホットスペアも dRAID 構成の RAID-Z2 も HDD が壊れた直後 にRAID再構築が実施されるのであってホットスペアを補充するタイミング じゃない dRAID の場合はそれに加えてホットスペアを補充した際にも再ストライプ 目的で2回目の再構築が走る=つまり2度手間 dRAID の1回目の再構築の際にはパリティ計算している だから2回目の再構築の時は不要ってだけだ パリティが要らないっておかしいと思えよ read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる