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

>>892
>SSDが物理的に破損するなんて無い
そなの?

熱で歪んではんだクラックすることはあるよ
基板を使った全ての電子機器に言えることだけど

>>892
物理的な破損じゃなくてもコントローラーのバグでデータ消失とかあるだろ。SanDiskとか。
バックアップは物理的に分けるのが基本。

＞それともその上のcpコマンドとかrsyncでファイルとして複製するのかな?
そうだよ、スナップショットをマウントして、ファイルを「別の場所に」コピーしてはじめて正当なバックアップと言える。
これらの手順を簡略化できるsend/recvコマンドが用意されていて、
こっちの方が効率いいし、メタデータも丸ごとクローンできる。

>>896
>そうだよ、スナップショットをマウントして、
なるほどね
俺はrsyncで良いや
夜中に寝てる間にやるから問題なし

/をスナップショット撮ってその領域を別筐体にrsync or cpし、ブートローダー入れれば普通に動くものですか？
やはりddが必要ですか？

/var以下とか書き込み途中のファイルがあるだろうから
そこは影響あるかもしれんが多分大丈夫でしょ

Debianは単なるマウントポイントで起動ディスクを指定してるから動く。
FedoraはUUIDで起動ディスクを指定してるから動かない。

SSDはHDDより気楽にセルが死んで内部のECCで誤魔化すつくりだから大手のちゃんとした奴でも壊れないって発想は絶対できないなあ
まあ結局は本人がどれくらいの信頼性とデータの保全を重視してるかだけど

SSDは電気的に壊れたりしそうだしHDDより信頼していいとも思えない

ＨＤＤのような故障の予兆はネエと思った方がイイですぬ

マジで重要なデータならHDDはデータ復旧業者に持ち込めばほぼデータ救える
SSDは難しそう

ガタが来てもカリカリ言ってくれないのは怖い

>>900
DebianだってUUIDで指定してるぞ

>>900
>起動ディスクを指定
って何のこと?

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は正常
カーネル４系だけどもう６出てるの？

いまだにラズパイがbtrfsに標準対応しない理由が全然わからない

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 でドライブ１つ死んでも sync できちゃうものなの？
その状態でマウントが read-only に落ちないのは不具合ではあると思うんだが。

BcachefsがやっとLinuxにマージされたぞ

きたか…!!
　 ( ﾟдﾟ)　ガタッ

Trying Out & Benchmarking Bcachefs On Linux 6.7
https://www.phoronix.com/review/bcachefs-linux-67

>>928
微妙……orz

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を置き換えられるのか等運用や評判の話は良くも悪くももっと後だろう

キャッシュなんてベンチマークしてとうすんねん

Btrsfに暗号化きたぞ
https://lwn.net/Articles/947316/

fscryptかあ…dm-cryptの方が好みかなあ
ただ現状btrfs raid dmcrypt automountの連携に難ありというか…正しく調整するにはudevまでいじる必要があるのが面倒

ファイル暗号化だとシステムはTPMで暗号化して(起動時のパスワード入力不要)
ホームディレクトリはログインパスワードで暗号化といった使い分けしやすいのが利点らしい。
ユーザーが大量にいるケースでも個別のフレーズで暗号化出来る。
同じことを他の方式で実現するのは現実的ではない。

予行練習で試しにext4のfscryptを使ってみたけどめっちゃ便利だなこれ
ログインしていないユーザーのhomeフォルダは暗号化されたままだからdm-cryptよりも安心感がある
ほぼ起動したままだったから全体の暗号化にあまり意味を感じてなかったし

xfs敗れたり～

Fedoraはfscryptによる暗号化をインストール時のオプションとして提供する計画みたいだね
xfsからbtrfsに乗り換えたディストリの強みを活かしていく

ブロックグループの導入でマウントが遅い問題も解決されたし
Btrfsは最強のファイルシステムへの道を着実に歩んでいるな

bitlot防止機能が素晴らしい

なぜ窓と林檎はbitlot防止できないんだい？

bitlotってなに？

マジレスするところなのかボケるところなのかわからんけどbitrotのtypoじゃない？
どう優れてんのか知らんけど

bit rotという言葉は初見だったので勉強になりました。
ありがとうございます。
bit rot防止login:Penguin

圧縮って使わないほうがいいかも
CPUが100%張り付いてる状況だとめっちゃ低速化する

CPUが100%に張り付くようなマシンスペックが問題ってだけ
圧縮や重複排除はコアとメモリに余裕がないマシンでは使えねーのは
今も昔も変わらん

ソースベースディストリで作業ディレクトリをcompressオプションでマウントとか？

結局Btrfsはやめてext4に乗り換えた
Btrfs自体は安定してくれてるんだけど
たまにext4に決め打ちされてる古いプログラムを踏んで不具合が出るのがキツかった

Linuxは素晴らしいよね。

>>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は断片化が起きる前提にファイルを配置していくからデフラグの意味がないんだよ
だからデフラグソフトが無い

NTFS は FATと違うのでデフラグは起きにくいし、実行しても短時間で終わるでしょ。
https://atmarkit.itmedia.co.jp/fwin2k/experiments/defragment/defragment_column.html

デフラグせんでも別ストレージにコピーすればいいのだ

e4defrag は

SSD時代にデフラグ要るのか？

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で良いんですよね？

良いよ。
大半のパフォーマンスはext4が一番良いくらい。
xfs はファイル数などの上限が上がるので企業みたいな使い方をするならよい選択。
btrfs はCoW で条件によりコピーが速かったりファイルシステムを圧縮したり、高機能だし色々出来るけども、使い方を調べないといかん。

確かにext4はコピーが激重。

昔xfsでファイル削除が激重だったけど、何年か前に改善されたらしい

https://www.phoronix.com/news/ReiserFS-README-Linux-6.10

Hansが獄中で更正してるのに泣いた(´；ω；｀)ﾌﾞﾜｯ

日本語版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年ちょっとだが今のところド安定だわ

過去ログ読んできてbtrfsのRAID5/6には問題ありというのを知って
あれから色々更新入って対策進んでる様だけどまだ例の問題は解決してないっぽい!?

RAID5はLinux6.2以上なら信頼できそう
RAID6はまだです

RAID5にするくらいならRAID10でってなっちゃう
早くRAID6不具合なく使えるようにならないかな

btrfsは今もマウント毎にオプション指定出来ないままなの？

Btrfsが安定したって嘘じゃないか。RAIDがまだ不完全。