ファイルシステム総合スレ その19
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には限らない