ファイルシステム総合スレ その19
レス数が900を超えています。1000を超えると表示できなくなるよ。
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はデータ復旧業者に持ち込めばほぼデータ救える
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は正常
カーネル４系だけどもう６出てるの？ いまだにラズパイが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にマージされたぞ レス数が900を超えています。1000を超えると表示できなくなるよ。
