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

>>851
スナップショットのあるファイルシステムいいよ
いつでも全ファイルの差分が見えるし、バックアップ取るときもまずスナップショットを取ってそっちを対象にすれば
メインボリューム側では整合性期にせず作業続けられるし

>>855
Fedoraのデフォルトになって数年が経過しているから安心していいよ

Btrfsの透過圧縮でわざわざ標準外のレベル設定するのってだいぶ特殊用途なんでは…？

Fedoraチームがベンチマークを取ってzstd:1がベストと導き出したんだよ

5年以上 zstd で btrfs使ってたけど自分は問題無かった。
今はZFSでzstd使ってるけどこっちも問題ないよ。

>>860
btrfsからzfsにした理由とかある？

>>861
理由はproxmoxに移行したため。

純粋なストレージプールが欲しいならzfsやcephあたりで良いんだろうが
仮想化ゲストならvirtiofsが主流になって使いやすくなってほしいなぁ

>>862
サンクス

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だったら中がぐちゃぐちゃでもそれ片付ければ済むんだよ
焼くこともできない惨状

VDOつこうてる人おる？

あなるせっくす

結局またext4+lvmにしてしもうた

xfs+lvmでおk

もはやBtrfs以外は使わない理由を説明する必要があるレベル

btrfs難しいよ
どういう使い方が標準なん?

zstd:1で圧縮して時々スナップショットを取る使い方が標準だよ
バックアップを一瞬で取れるから派手にファイルを扱える

>>874
いうても同じボリュームにスナップショット取ってるんやろ？

スナップショットとバージョン管理は根本的に似てるような気もする
gitとbtrfsで何かfusionできないかな

言われてみると rsybc の差分バックアップで間に合うような気もする

rsync

俺は2005年くらいから毎日差分バックアップしたhomeディレクトリがある
当初はpdumpfsで途中からrsyncを使ってとったもの
つまりファイルに差分がなかったらハードリンクにして容量増加が抑えられる
ファイルとかハードリンクとかは当時から何も変わらないからまだ使えるんだけど
その下のストレージもfilesystemも開始した当時とは全く変わってしまった

普通の差分バックアップとBtrfsなどのスナップショットの違いは
ゴミ箱に放り込んだ後の挙動だね。
普通の差分バックアップは一応次のバックアップまでは容量が回復するけど
Btrfsのスナップショットだと、一度でもバックアップをすると
以降はファイル削除で逆に空き容量が減ったりという奇怪な挙動になる。

言いたい事は分かるがワケワカメ

スナップショットそのものをバックアップとして運用するんじゃなくて
スナップショットで瞬間を固定したものを別の物理ドライブにバックアップするんやで
使用中のデータをバックアップするよりも整合性の心配をしなくてよくなる

>>882
それ、スナップショットを別の物理ドライブに取ればええんでないの？

スナップショットの仕組みがわかっていない奴だな

昔使ってたストレージを思い出した。
データベース停止→同期ディスク切り離し→データベース起動→切り離したディスクからバックアップ→ディスク同期
データベース停止から起動まで5分だけど、バックアップは10時間とか。

スナップショットはバックアップではないと何度言えば解るのか

RAIDだってバックアップじゃないぞ！＞昔の俺

スナップショットも全部別ボリュームにバックアップや

俺はスナップショットを使ったことないんだけど
スナップショットってある時点のファイルシステムの状態を
保存できるというので良いのかな?
スナップショットってのは何回も取れると思うんだけど
するとこれらをバックアップしようと思ったら
他のストレージに複製する必要がある
それはフィルシステム階層でやるのかな? 複製されるのはフィルシステムのイメージ?
それともその上の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はデータ復旧業者に持ち込めばほぼデータ救える
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カードを選ぶ必要がある