ファイルシステム総合スレ その21

● 前スレ
ファイルシステム総合スレ その19
https://mao.5ch.net/test/read.cgi/linux/1592027147/l50
ファイルシステム総合スレ その20
https://mao.5ch.net/test/read.cgi/linux/1722312892/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 あたりで.

これもファイルシステムの話かな

`cp`はディスク上ではデータをコピーしないことがある
https://zenn.dev/satoru_takeuchi/articles/4bab372c6dae86

ただのCoWやんな

SSDの普及で普通の方がHDDを使う機会が減りましたが
NASのHDDのフォーマットをBtrfsからext4に変更したら管理方式が異なるのでアクセス音が全然違う w

AI時代になってNTFSのACLが光り輝いてる
PCは自分しか使わないという前提ほぼなくなった

>>175
btrs使ってるけどコピーしてみたら時間かかった。なんかUbuntu 22.04.5 LTSだとcoreutilsのバージョン古くてcpコマンドは旧来のファイル本体を常にコピー

でcp --reflink=always でコピーさせたら1ギガあるファイルも一瞬でコピー完了（Cowなので当たり前か）
いやbtrfs使ってたけどこんな凄いのね、Cowって牛みたいな名前でもなんか凄い

CoW って実運用で役に立つシチュエーションが殆どないと思うんだがどうだろう？

中身重複してるキャッシュファイルが結構あるからディスク節約したいけどハードリンクはしたくないときにjdupes -B

「中身重複しているキャッシュファイルが結構ある」ってどういう運用するとなるの？
重複するキャッシュ作ってる時点で実装側の問題？

実際にjdupes -r ~/.cacheやってみると結構見つかると思うよ

CoWあるとバックアップが凄まじく捗る

>> 183
やってみたが正直運用が最適化されるといえる物量には思えないって感じたわ

>> 184
それスナップショットであってバックアップじゃないのでは...
もしくは「重複排除あると...」の間違いか

さておき重複排除実装したらおまけでついてくるのが CoW って考えることにするわ

SMRのHDDをxfsからbtrfs (raid1)にしたら
プチフリしまくり
claudeに聞いたらCoWとSMRは相性最悪らしい

CoWというよりSMRとRAIDの相性が…

スナップショットを取る→スナップショットの内容をバックアップする→スナップショットは消す

直接バックアップすると途中で書き換えが起こったら不整合になる。スナップショットなら瞬間を切り取れる

あれ!?xfsってカーネルによってはCoWサポートしてなかったっけ？

xfsのCoWは機能としてはあるけど使い物にならん

スナップショットに夢見過ぎだってば

スナップショット取ったからって稼働中のDB製品やアプリが使ってる DB を
バックアップモードにしてくれるわけではなく(ファイルシステムレベルでは
担保されるが)コンテキストレベルでは整合性は担保されない

逆に突然の電源断とかでも vi のスワップファイルやら MS Office のバックアップ
ファイルで復旧するし、アプリのDBもなんだかんだ勝手にロールバック/ロール
フォワードで良しなに整合性回復処理するから言うほどスナップショットなくても
整合性はそこそこ確保される

どのみちバックアップする時はDBは停止だかフラッシュだかさせるでしょ
そのままバックアップが終わるまで待つところをスナップショットを取ってしまえば停止時間を最小にして作業も再開できる

>>192
DBを使うWebアプリが[1]全データをDBに格納している場合は
DBをバックアップモードにしてバックアップすればファイルシステムで
スナップショットを撮らなくてもコンテキストレベルで整合性が取れる

そうでなくて[2]DB以外にもファイルシステムにデータを格納している場合
DBをバックアップモードにしてファイルシステムでスナップショットを
撮ったとしても整合性が取れているとは限らない
# OSのシステムコールの fclose (ファイルシステム側データ) と
# DB の commit (DB側データの書き込み) をアトミックに実行
# はできない

もちろん WebアプリケーションサーバとDB両方停止してファイルシステムで
スナップショット撮れば整合性は取れるよ？

でも「フラッシュだかさせ」てって書き込んでるのは運用的には危うい

まさに夢見過ぎだと思うんだわ

いや君がDB言ったからDBで返しただけで、Webアプリケーションサーバとか次々と新しい条件を出してくるんじゃないよ。バックアップの時は当然それも停止するだけでしょ
意味なくゴールをずらすんじゃないよ

>>194
コンテキストレベルで整合性取れないって意味が分かってないから
詳細説明したのであってゴールポストはずらしてないよ

そうでないならどう解釈したか教えてよ

ごちゃごちゃこの場合はだめと仮定を足してきてるのはそっちでしょうが
そりゃ普通にバックアップを取るときに気をつけないといけないようなことはスナップショットを取る瞬間も気をつけないといけないよ
停止時間を短くできるだけであって

腹が立ってきたな
要は先回りして全部の注意事項を書かないと相手を理解してないことにしてしまう絡み方であり、レスバがしたいだけのやつだ

こちらはスナップショット過信するなと書き込んでるのに
火種となる楽観論で返してきたのはあなたでしょうに

>>90
いつのまにか、この症状が出なくなってる
zfs-windows-2.4.1rc10以降で確認

細かい機能を使わなければ常用には問題なさそうなので
いよいよゲーム用PCと録画用PCを組めそうだ
全部をSSDには出来ないからL2ARC機能に目を付けてたんだ

バックアップリストアのシナリオいくつも作ってテストしても、どうせ一度も使わないんだよな

バックアップの出番が無いのは良いことだ

oracleをノーアーカイブモードでVSSとるだけの人は結構いると思う
厳密に言えばだめなんだけど、どうせリカバリする機会なんてないから気づかないよね

株式会社アイ・エス・ビー
https://kizuna.5ch.io/test/read.cgi/infosys/1756826944/

https://archive.md/Zg0Yp
ISB人事

virtiofs

DB 担当→DBバックアップなんてプログラマは勉強しないっすよ。 バックアップソフト担当が何とかしてくれるよね！？
バックアップ担当→Oracleの詳細なんてわかりません！！
で結果ノーアーカイブログモードで運用なんだよなあ

ここから１歩だけ進むとバックアップ担当が「Oracle わからんから
Disk To Disk でこのファイルだけバックアップしてくれ状態で引き渡せ
(= RMAN で自分たちで責任もってファイルバックアップしろ)」って
DB担当に念押しする形になるんだが、これはこれでバックアップ実行と
RMAN 実行が重なってたら意味がないという...

https://www.phoronix.com/news/Btrfs-No-Serialize-Direct-IO
Linux 7.2で導入されるBtrfsの変更により、非常に優れたパフォーマンス向上が見込まれる
Michael Larabel

DirectIOが60%向上とか。

Linux 7.1のアップデートで、Btrfsはファイルシステムの「シャットダウン機能」が実験的 (experimental) から安定版へ昇格しました。これにより、ファイルシステムエラー時の動作の信頼性が向上し、各種のパフォーマンス改善とバグ修正も導入されています。

Linux 7.1におけるBtrfsの主な変更点
シャットダウン ioctl の安定化
ファイルシステムの強制シャットダウンと待機中の処理を安全に完了させるためのメカニズムが安定版になりました。XFSなどで実装されていた仕組みと同様のものが公式にサポートされています。

・ エラーハンドリングの改善
ファイルシステムエラーを報告する FSERROR メカニズムに対応し、トラブル発生時の診断がしやすくなりました。

パフォーマンスと最適化
全体の動作効率化や、各種バグフィックスがマージされています。

btrfsの弱点な速度が改善したら最強か？！

direct IO使ってるソフト見たことないけど

最近ext4を愛する事が出来るようになって分かったのはbtrfsはスナップショットとか使わなかったら宝の持ち腐れだからなぁ

どのフォルダをスナップショットで戻しているの？
/home /work といった自分が作ったデータ以外というのも範囲としては楽とも思うけど

2023年のミスでDirectIOが最適化されていなかったが
修正したので59%スループットが向上したって事かよ、つまんねー

>>209
DBで使われてるみたい

(debianスレと重複になりますが)
JFSっていつまでサポートされるのだろう。。。

メンテナのやる気がなくなるまで

自分でメンテナンスすればいつまでもサポートされるのがOSS

メンテナンスできるスキルがあれば、ね

そこでAIが颯爽と登場

bcacheFSはAIを最大限活用して
一人とは考えにくい速度で開発を進め
周辺ツールやドキュメントまで整備した
しかし作者はAIに囚われ暗黒面に堕ち始めてる

>>206-207

rust みたいなクソ言語をカチ込んだカーネルなんて信用しない

>>219
よかったね。古いOSしか使えなくなっていくよ

古いというコトバは中身がない

何が悪いのか善いのか何も指摘していない

知恵遅れが使い易いラベリングだから多用するけどねw

いやさすがにブーメラン刺さってません？
例文：
クソというコトバは中身がない

何がクソなのかクソじゃないのか何も指摘していない

根拠もなくディスるだけのカスが使い易いラベリングだから多用するけどねw

>>219
代わりに何のカーネルを使うの？

マカー派かもな
ファイルシステムに関係するか、分からないが。

Macはカーネル開発にswift使い始めてるけど
swiftって単純にシステム開発向けの言語じゃないよね
パフォーマンス悪いし
javaのほうが高速なくらい

え？SwiftはC++と遜色ない速度出るけど？

Swiftは書き方によって随分違うぞ、手続き型っぽい泥臭い書き方すりゃ速いが。Common Lispみたいなもんだ

LinuxはRustに置き換わるのかな

Linux のカーネルで使われている言語はアセンブリ言語、C言語、Rust だけ

その内ぬるぽを回避できるのは Rust だけだからそうなるんじゃない？

>>229
少しは調べろ
https://github.com/torvalds/linux

>>229
ガッ

ダウンロードしてファイル名の拡張子調べたけど、アセンブリ言語とC言語とRust
だけにみえるが何について指摘しているつもり？

シェルスクリプトだとかPythonやPerlもあるっちゃあるが
ビルドツールであってソースではないよな

>>223
サンダース

>>233
サプライチェーン攻撃(ニチレイ)でシャットダウンしそうなんですが

https://www.phoronix.com/news/Btrfs-No-Serialize-Direct-IO
Linux7.2でbtrfsのDIOスループットが大幅に
向上したらしい。

MANJAROで
> BTRFS users DO NOT install kernel 7.2rc yet
というアナウンスが流れてたのはそういう大手術の影響だったんですね。

ナニソレ
こえーよ

>>235
先月すでにこのスレで扱ったネタだ >>206
あと大幅に向上したのではなく不具合で大幅に低下していたものを修正しただけな

AI Agent上で同一fileが多数作成される環境という条件付きだが、興味深い翻訳記事。
タイトルはAppleのAPFSとの比較だが、記事中にLinux対応各FSとの比較もあり、XFS+VDO
(LVMに圧縮・重複排除のpoolを作成する技術)の性能が際立っているとの評価。

テオ氏：アップルのファイルシステムは遅すぎる——AIコーディングを全てLinuxに移行し、
ストレージを3分の1に削減　2026-08-21 06:08 (GMT+9)
https://finance.biggo.jp/news/a1cc91818da11d06

単にpnpmがLinuxではcopy_file_rangeを使ってAPFSのファイルクローンシステムコールは使ってないだけな気もする…

ファイルシステム色々試したいならMiniTool Partition WizardでFAT32・exFAT・NTFS・Ext系・Linux swapまで一通りいける

>>239
いいねえ。
mdadm→VODインストール→xfsでいけるかな。試してみるわ。

>>241
> MiniTool Partition Wizard

なんで実績のあるGPartedがあるのにそんな得体の知れない野良アプリ勧めるの？

Ext4が至高
XFSはパフォーマンス差が小さい 大規模なら若干需要ある
Btrfsは不安定 ややこしい仕様 RAID5/6非対応

Btrfsが不安定っていつの時代の話してんだ

>>245
>>244 が言いたいのは「あなたの考える不安定」ではなく
「前者と比べ比較的信頼を置き辛い」って事なんじゃないかな

しかしそれは置いておいても >>206,236 とかの話がでるあたり
不安定って言われてもしょうがない気もしない事はないが

ファイルシステムは枯れたのを使うのが定石

リスク回避して安定求めるならそうだけど
かといって古い物に固執して時代に取り残されて認識アプデできない思考が染み付くのもそれはそれで問題だな
PC界隈にはそういう人多いし

Btrfsは内蔵のRAID5/6に問題がある。

正直RAID5/6使わないし……

BTRFSを4TBx5のRAID5で運用してるが、今のところ問題はない。UPSのエラーで電源断したこともあるがエラーは出なかった。
でも海外サイトに膨大なデータ（数百テラ）をBTRFSにコピーするといつまで経つても終わらないという書き込みはあったな。

8TBのHDDを同容量にコピーするのにも1日近くかかった記憶が
HDDだとしたらRAID5/6のストライピングで加速があるとしても
数百TBは10日やそこらじゃ終わらなそうな…

最近btrfs導入してHDDがCMRかSMRかを気にするようになった
SMRだと十数秒固まることがまちまちある

それhdd休んでるんじゃね？

7200回転のHDD使ってないだけちゃうか？
5000回転と比べて3倍位速くなったぞ

>>255
え！回転数でそんなに変わるの？

>>256
完全フォーマットの時間が
7200で8h
5000が24h
位違った
サイズは8Tだったかな
メーカも違うが..

仕組みが全く分かってないんだが3倍ってどこから出るんだろうね

7200.0 / 5000 = 1.44
1.44 x 1.44 = 2.0736 おお! 割合を2乗すると2倍になるのか...

うーん
誰かおせーて

キャッシュじゃないの

"Linux HDD SMR 運用" でググったら AI さんが

絶対避けるべき運用 → OS インスト/DB/VM/P2P/RAID
ファイルシステム → EXT4=無難, XFS=悪くないが特化した設定が必要,
Btrfs/ZFS=CoW方式なので断片化が激しく起こり速度急落

とのこと

あとSMRタイプのHDDはSSDみたいにTrimが必要なんだけど
機種によってはTrimの機能実装がなくて
んでTrim機能が無い場合アクセスしたタイミングでガベージコレクトが
発動してストール発生、とかなんとからしい

3倍なのは古い5400rpmのHDDで断片化が進んでいた+Trim機能なし
だった可能性があるな

SMR ダメすぎて 10TB ぐらいより上のモデル以降では各ベンダー CMS に戻してるんだよな
あきらめて新しいHDD買いなよ
なおまだ店にはSMRが並んでいる模様

>>260
両方新品やね
最初は完全フォーマット教なので必ず全域舐めてから使うんよ
なぜ3倍も差が出たのかはわからん

OMV（Debian）にMDRAID5+VDO+xfsを入れようと苦戦中。

①OMV GUI：raid5ボリュームmd0作成
②ssh：物理ボリューム作成
③ssh：ボリュームグループ作成
④ssh：VDOモジュール作成
⑤OMV GUI：xfsファイルシステム作成
→lsblkでmd0下にVDOの階層構造を確認

ここで再起動してlsblkするとmd0以下のエントリがすべて消え、md0だけになるw

ぬわぜた？

あうあうあー
うちの数年前に買った6TBもなんか書き込み時にアクセスLED付きっぱで
処理が帰って来ない事あるなと思ってたが、よくよく型番確認したら
SMRだった
なるほどだから容量の割に安かったのか

ちなみにファイルシステムはext4だけど、btrfsとかにしてたらもっと
悲惨な事になってたんね…

>>263
RHEL5 の頃に LVM だったか Soft RAID だったか、そういうのなしで
OSインストールした環境に LVM?/Soft RAID 作って同じような症状でたことあるわ
その時の対策は initramfs 再作成だったよ

>>265
ありがとう。昨晩RAID5作ってリシンク終わるまで放置してるので、今晩試してみます。

>>264
btrfsはチェックサムがあるんでどっちがマシかはわからんよ
もちろん検出できるだけマシという考え方も、データが壊れたら終わりには変わらないので書き込みの絶対量が少ないext4がマシという考え方もどちらもあり

ところでフラッシュメモリいたわり用に作られたものの他の媒体でもそれなりに効果発揮することが知られてるf2fsさんはどうだろうね

Ext4っていまだにbit rot対策無いじゃんヤダー

>>263 です。
なんとかうまく行きました。まとめ終わったら報告します

>>268
SDカードにインストールしたLinuxで使ってるけど他のfsより確実に破損しにくい
まあ中華ノーブランドのゴミみたいなやつだからそれでもたまに壊れるんだけど

OMV8（Debian13）でraid5+VDO+xfsに失敗した原因
→OS起動時にVDOカーネルモジュール読み込み（dm-vdo：kvdoはもう使われていない）や LVM のスキャンが間に合わず、マウントエラーでシステムが停止する。
これを防ぐため/etc/modules、/etc/initramfs-tools/modulesにdm-vdoモジュールを追加し、正しい起動順序を /etc/fstabに追記しないとダメ
#以下手順　
# パッケージのインストール
sudo apt update
sudo apt install mdadm lvm2 vdo xfsprogs
①raid5作成
mdadm --create --verbose /dev/md0 --level=5 --raid-devices=n（nは対象hddの台数） /dev/sda /dev/sdb /dev/sdc
#mdadm.conf更新
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
②物理ボリューム、ボリュームグループ、論理ボリューム作成
pvcreate /dev/md0
vgcreate vg_storage /dev/md0
lvcreate --type vdo -l 100%FREE -n lv_vdo vg_strage
③xfsファイルシステム作成
mkfs.xfs -f /dev/vg_storage/lv_vdo
mkdir -p /srv/storage（マウント先ディレクトリ）
④起動時にdm-vdoを自動でロードするように設定
sudo modprobe dm-vdo
echo "dm-vdo" | sudo tee -a /etc/modules
⑤initramfsへdm-vdoモジュールを追加
echo "dm-vdo" | sudo tee -a /etc/initramfs-tools/modules
設定を反映させるために initramfs を更新
sudo update-initramfs -u -k all
⑥ /etc/fstabに以下を追記
/dev/vg_storage/lv_vdo /srv/storage xfs defaults,x-systemd.requires=vdo.service,_netdev,noatime 0 2
⑦論理ボリュームの自動マウント
mount -a

>>272
vdo.service って結構前(kvdo廃止時？)に無くなったみたいなんだが...

そもそもローカルディスクのファイルシステムなのに _netdev オプションとか
存在しないサービスの依存関係で解決っておかしい

debian では update-initramfs を dracut ベースのラッパースクリプトにする
プロジェクトが進んでいるらしいが、それってつまり update-initramfs が
もうまともにメンテできない状態になってるって事じゃないかな

update-initramfs が作る initramfs では vdo のカーネルイメージのロードと
lvm の初期化の実行タイミングが正確に記述できていない懸念があるわ

>> 273
コミュはvdoをlvmに統合しようとしてるけど、Debian13を指定してAI検索してもdm-vdoではなくvdoコマンドやkvdoを使った解決方法や、initramfsの記載のない結果が普通に出てくる。
まだ導入数が少ないのかな。

メモリ使用量もOMV込みで6GGB前後で、zfsの惨状を考えると素晴らしい。読み出しにも解凍のタイムラグを全く感じない。

でも構築の面倒臭さを考えると、重複排除に目をつぶり、BTRFSのraid5+zstd:3圧縮も捨てがたいかな。