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

● 前スレ
ファイルシステム総合スレ その18
https://mao.5ch.net/test/read.cgi/linux/1514472651/l50
ファイルシステム総合スレ その19
https://mao.5ch.net/test/read.cgi/linux/1592027147/

● 関連スレ
ジャーナリングファイルシステム
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 あたりで.

encfsでwinのファイルがコピーできなくて困ったことならある

fedora のインストーラは btrfs を使う時、/boot 以外を一つのbtrfs パーティションとして作成してから、/ と /home をサブボリュームとしてマウントしている。
Debian のインストーラじゃ出来ない気がしている。

Debianだとbtrfsにすると/boot/efiを除く/以下全体がサブボリューム名@rootfsになる
細分化したいときはインストーラ終了後再起動前にライブイメージに居残って操作するといい

ファイルシステムって普通1つのファイルの最大サイズも〇〇バイトまでみたいな制限があると思いますが
tmpfsにも1ファイルあたりの最大サイズとかって決まりみたいなのってありますか？

知らんけど仕様の制限より先にメモリサイズの制限のほうが先に来るだろう

+------------------------------------------+
| A: Btrfs Send/Receive再利用試験 |
| (長期不使用機能、試験欲す) |
| (元snapshot: /timeshift/.../@, @home) |
+------------------------------------------+
|
v
+------------------------------------------+
| B: 現状確認・Snapshot所在確認 |
| (lsblk, mount /dev/sda1, ls) |
| (先ディスクにて発見: |
| /mnt/backup_btrfs/@_snapshot, |
| @home_snapshot) |
+------------------------------------------+
|
v
+------------------------------------------+
| C: 手動復元手順の複雑性再認識 |
| (fstab, grub, initramfs等手作業多) |
| (timeshift自動復元との対比) |
+------------------------------------------+
|
v
+------------------------------------------+
| D: `btrfs subvolume snapshot` の |
| 非破壊性確認 (Copilot助言) |
| (操作自体は安全、然しmount/fstab変更 |
| 伴えば現環境復帰煩雑の可能性) |
+------------------------------------------+
|
v

+-------------------------------------------------+
| E: 🔥迷い・目的の再評価 |
| 🌱「分離故安全か？...だが切替煩雑」 |
| 🌱「最悪時保険？...1.5年前状態に戻す価値薄」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| F: 🎯目的変更・作業範囲縮小 |
| 「今回は旧snapshotよりデータコピーのみに止む」 |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| G: Copilot追認 |
| (個別データ抽出・現環境維持を善策と評価) |
| (btrfsサブボリューム複製、現環境と分離独立) |
+-------------------------------------------------+
|
v

+-------------------------------------------------+
| H: 過去の最悪事態経験想起 |
| (timeshift --restore不能は稀有) |
| (手動snapshotは最終保険として有効と認識) |
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| I: 最終結論・認識 |
| 「苦労して整えし現環境を旧状態へ戻すは非得策」|
| (現環境維持優先、旧データは必要時参照) |
+-------------------------------------------------+

似たようなファイルシステムがゴロゴロあるな
同じような機能同じような目的

プロプラエタリィなNTFSの存在がガンですよ。

btrfs と bcachefs ならどっちを使うべき？

(Linus Torvalds) in August of 2024 that "nobody sane uses bcachefs and expects it to be stable".
ps://en.m.wikipedia.org/wiki/Bcachefs

>>897
草
Kent Overstreet 氏がなんかアレっぽいからやめとくわ

An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11
ps://www.phoronix.com/review/linux-611-filesystems

f2fsすげーな、SDカードいたわりファイルシステムってだけじゃないのか

F2FSはAndroidのストレージのファイルシステムに使われてるから
今はもうかなりのデバイス数で使われてる

おもしろそうな話をしているようなのできました

f2fsってのがあるんか

btrfsの更新履歴を読むと raid5 なら行けそうな気がしてきた。

Raid5はもう使っても大丈夫になってたはず
たしかLinux6.2から
カーネルバージョン低いと注意

RAID5まで使えるようになったらもうBtrfs敵無しでは？

>>904
Debain 12 (Bookworm) 2023年は6.1なのでDebian 13(Trixie)からは大丈夫になるのか。良い情報だ。

stableのカーネルって普通にbackportsのに
更新して使うものだと思ってた…
絶対にミスが許されない鯖とかでない限りは

レスチで悪いが、
Debian Backports に関しては Kernel で問題は出ないだろうけど、Backports でバージョン上げて不具合あっても、本家の解消待ちのイメージしかない。Emacs の事だが。

>>904
なってません
追加機能無しで出来る修正が一つ入ったってだけで
write holeは根本的に解決してないし
多分これからしばらくも解決されません

ttps://www.phoronix.com/news/Linux-6.2-Btrfs-EXT4
ttps://www.reddit.com/r/btrfs/comments/127zmsx/what_do_you_think_about_the_kernel_62_btrfs/

そもそもRAID5実装自体が完全に安全だと仮定しても
何TBのHDDでRAID5とかはリビルド中にUREに遭う確率を考えると割に合わない

Btrfs使ってるけどRAID10で十分だよ

リビルドなんてZFSでもそんな信頼性高いもんじゃないからどうでもいいわ
なんか壊れたら素直に再構築すべき

リビルドによる冗長性に期待しないんだったら
わざわざパリティ付きストライプで分散して書き込む理由なんて一つもない
そして現実的な容量あたりの回復不可能エラーの確率を考えると
6はともかくまともな冗長性が期待出来ないRAID5なんか今は使う理由はまるでない
それこそRAID1どころか多くの場合で破損部分が明白かつ単純で
無事な部分を吸える可能性が高い分だけシングル運用の方が遥かにマシ

リビルドによる冗長性ってなに？

RAIDはアレイが破損したらリビルドかける前に
全データバックアップしろが通説だと思った

バックアップする空きストレージがないとか
そもそもバックアップがないなら
そもそもその運用がおかしい…
(捨ててもいいデータだけとか観て消し録画は除く)

なんでRAIDやりたがるのか意味不明
バックアップの工夫をそれなりにやって
ダウンタイムやデータ損失期間を減らすための最終仕上げだよね
それとも広告であるネット記事を見て導入が大半?

>>913
ttps://e-words.jp/w/%E5%86%97%E9%95%B7%E6%80%A7.html
ttps://www.buffalo.jp/topics/trouble/detail/recovery_0005.html
RAIDの文脈で「冗長性」ってのは
RAID構成内に故障したハードウェアが出てもデータの完全性が損なわれない事
「リビルド」ってのはもっぱらその故障したハードウェアを入れ替えて元の冗長性を持つ構成に再構築することを指す
この説明でわかんないんだったら俺にはうまく説明出来ねえ
「リビルドできる冗長性に～」の方がもっと正確な言い回しだったといえばそれはそうなので
わかってて言ってたら単に俺の日本語が下手でごめんだな

>>914-915
本当にクリティカルなデータを扱うなら
定時記録的なオフラインバックアップが常に別にあって
「退避」や「サルベージ」をやる必要すらほぼ無いのが理想だし本当なら当然
もちろん実現にはハードウェアも運用もコストが相応に要るので難しくなるけどね
冗長性が無い状態での改めての読み出しは
結局リビルドとやってる事は似てて当然ながらもし残りのハードウェアが故障すれば(読み出せなくなった分は)完全にパーなんで
これはどちらかというと現実的な次善策

それこそbtrfsならスナップショットとsend/receiveをうまく使えば
オフラインバックアップ用の場所にも高速に増分バックアップ出来るよ

btrfsのsnapは呆気ないほど簡単にファイルの先祖返りが長期も短期も可能で、
WinがやっているVolume Shadow Copyの上位互換って印象で、個人的にはとても好き。

でも、バックアップは別途必要かなって思っている。神経質なだけかもだけれど、データって一番大事だから増分・差分だけじゃなく、本体も自分は保持するようにしている。

>>916
冗長性ってリビルドのためではなくサービスを止めないためのものでは？
リビルドしなくても冗長性は重要だよ

びっくりしたのはRAIDでリビルド機能が無いと言われたとき
そりゃまぁデータ消えないけどそのまま運用とか狂人だろうに
おーこわいこわい

>>917
btrfsなら親になるスナップショットを指定して増分モードでsend/receive出来るから
外部にも、
つまり「バックアップ」もスナップショット構造を維持しながら
書き込みは増分だけで済むよって話なんだ

例えばオリジナル上でSnapperで毎日撮ってて06-15→06-16→06-17とかあるとして
同一の06-15が送受信するストレージ上に同時にあれば
それを親に指定して06-16は差分だけ転送で済む
そして06-16が同時にあればそれを親にして06-17は差分だけで……で継ぎ足し出来るわけさ
ttps://btrfs.readthedocs.io/en/latest/Send-receive.html

>>918
だから「RAIDの文脈で」って前置きして例のURLまで出してるでしょ
「RAIDの文脈で言う『冗長性』は主にはグループのうちn台が故障してもデータの完全性を保ち、そこからリビルドが出来る事」であって
例えば何かしらサーバーとして運用されてる物ならその全体の可用性として
一般的な語句で言う「冗長性」が望ましいというのは事実だしあんたは何も間違ってないけど
それはファイルシステムとデータだけに留まらない話

「たとえリビルドをしなくても全体の冗長性が重要」なんてのはそりゃ当然だけど
ファイルシステム総合スレなんだから
第一にファイルシステムとそれに関連するデータ保存の目的の文脈で話をしてるに決まってるじゃん

リビルドは最初からあまり期待しない。
HDDがいかれたときは他のHDDも寿命間近で、リビルド中にお釈迦になった経験がある。

raidを使う利点はコントローラから警告音が盛大に出ることとバックアップの時間が稼げること。

ソフトウェアraidの利点も時間稼ぎかな。

業務用ストレージならスクラブが走るからリビルドあんま失敗しないけどね
最近は別の不具合でボリュームが全損するケースがちらほらある
ストレージも最近高いくせに品質悪いな

RAID1ならリビルドするけどRAID5や6はやらないかなあ
時間かかりすぎるよ

> バックアップの時間が稼げる
これが大事だと思う

時間稼ぎだからデータ逃がせる環境ならraid5で十分だよ。

リビルドせずにバックアップ取得
ならRAID不要の環境だし普段からバックアップしとけよ
どれだけ踊らされているのか

>>926
どういうこと？
リアルタイムバックアップしろってこと？

バックアップは毎日取るものでしょ
差分だけなら時間もわずかなので

なんでRAID縮退時にバックアップを取る前提なの?
普段からとってないの?

日に一度のバックアップならやっぱりRAID必要やん
なぜそれでRAID不要になるのか

「壊れた瞬間に使えなくなる」のか、「まだ使える/処理を継続
できる」のか、はかなり重要なファクターだと思うが？
流石にバックアップあればRAID不要は極論。

ハードウェアRAIDはスクラブやらSMART監視で部分的な故障まで
監視しているからリビルド失敗はない。
失敗した場合でもRAIDカード交換させたら治ったこともあるから
似たようなことがったらカード交換も検討するといいよ。

LVM,ファイルシステム,デバイスドライバーによるソフトウェアRAID
やらフェイクRAIDも「４～５年ごとにハードを買い替える」ことが
守れてば大丈夫だと思うけどねぇ。

優先度について述べているだけ
バックアップを定期的に取らないのにRAID導入しているのが見受けられる

バックアップに対する現場の意識が足りない、という意味で言いたいのは
わからんでもないが、データロストと(RAIDなし環境における)業務/納期
遅延のそれぞれリスクを発生確率を交えて考えると、やはりその意見には
賛同できないよ。

一切の故障がなくてもURE(回復不可能な読み取りエラー)は確率的に起きるのでまず前提が間違ってる
もちろん製品のグレードによりけりで
エンタープライズ用HDDなら限りなく低い確率、具体的には10^15ビットに1回になるぐらいの品質で製造されてるけど
どのHDDにも起き得るし一般的な民生用だと10^14ビットに1回程度で更に確率が上がる

TB単位のストレージでRAID5が現実的じゃないってのは
読み取るサイズが増える分だけURE=リビルド失敗の可能性が高まるから
8TBだと仮定して民生用だと約60%、エンタープライズ用でも約6％ぐらいの確率で失敗する可能性がある

んでRAID1なら片肺でも読み出し出来るし
リトライも容易だけどRAID5じゃそうはいかねー事が多いからな

RAID5,6は理論上の速度や容量効率は利点だけど、
データチャンク、XORパリティで細切れブロック配置したり複雑で
ディスク上のビット単位でのデータ信頼性という意味では
物理ヘッドガチャガチャするHDDではRAID0よりキツそう
(そんなに詳しくないから想像だけど)

実際には様々なレイヤーのパリティやビット訂正で
エラー回復してるんだろうけど、自分が使ってる
RAID1(Btrfs)でさえ3週に1度スクラブかけると
半分ぐらいの確率でエラー訂正しましたのログが残ってるのだわ

URE(回復不可能な読み取りエラー)
というのは媒体mediumエラーでしょ?
HDD/SSDコントローラは生きていて
特定LBA(LogicalBlockAddress)でエラーがでる
局所的ブロック、媒体エラーだよね
HDD/SSD内部でソフトウェア的エラーの可能性はあるけど
カーネルから見たらハードウェアエラー(==故障)だよ
これ範

あとRAID使っているわりには
ファンや電源の冗長化してないよね
これらも故障したら交換するまで停止でしょ

>>933
言われてみればそうだなあ…
HDDだけダウンタイムなしまたは交換時間オンリーを想定してても、
HDDの故障率と比べて電源やファンとかM/B等パーツが
それより壊れないかと言うとうーんって思う…

自分の環境はファンは予備があってすぐ交換できるし、
電源はACアダプターのマザボ運用してるのでちょっとマシ
(ノート用のよくある19VでOK)

>>933
は事実と異なる内容を記述している
あるHDD/SSDでURE(回復不可能な読み取りエラー)が出たら
RAIDレベルによらず全HDD/SSD稼働中なら他のHDD/SSDのデータから復元できる
(要は1台故障と同じ(切り離して故障にするかは別問題でコントローラの設計))
HDD/SSD故障があるのならRAIDレベルによらず多重故障でデータ復元できない
RAID6は2点故障でも復元できるけど

現場的には6%はかなり盛り過ぎだと感じるわ。
RAID のチャンクサイズ考慮して計算されてないか、
スクラブとかSMART監視とかない前提？

>>938
だから「リビルドがUREで失敗する確率は決して低くない」という話だって言ってるじゃん
冗長性のあるRAIDレベルで通常稼働時に単一の障害が訂正出来るのは当たり前じゃねーかw

>>939
あくまで「リビルド中にUREに遭遇する確率」をカタログスペックから単純計算(概算)した数字の話なので
もちろん実際の障害の可能性はもう少し前後し得るよ

改めて補足しとくけどUREはSMARTとかからわかる形で
明確に「故障」せずとも読み取り時に偶発的に起きる確率的現象で
だから市販製品のデータシートにもちゃんと書いてあるんだ(Non-recoverable errors per bits readの項とかその辺り)
もちろん業務用途ならHDD/SSDにしろRAIDカードにしろソフトウェアRAIDにしろ
ずっと上等で堅牢な構成を採用してる事が多いから
破滅的な結果に至る確率はぐっと低いよ
あくまで典型的には個人がRAID5やるシナリオだと致命的になりがちって話ね

ttps://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-red-plus-hdd/product-brief-western-digital-wd-red-plus-hdd.pdf
ttps://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf

5分停止したら何億とか会社消滅ならRAIDでサービス継続は分かる

でも個人用途ではHDD故障して機能のバックアップで十分
データ書き戻しで半日くらい止まっても大丈夫
これらが大半
RAID不要だろって話
webや雑誌記事でのせられて使っているだけでしょ?

昨日のバックアップデータで許容ね

linux板って個人と企業を混合して話をするからエスパー力を必要とされるね

>>934
3週間間隔でエラー補正かかる、は流石にディスクの方を疑おうよ…

以下チラ裏。

週１回スクラブ、週の書き込みが総容量の15%程度でディスクの
使用率90%、8TBx11本(10d1p)、エラー率1/10^15、と仮定して
自分で計算してみた。

10d1pでスクラブなしで１本故障時に残存HDDにエラーが乗って
いる率(任意の10本にエラーが乗っている確率)が8%。
スクラブで 0.00000000028% に低下(面倒なので0%とする)。
１週間分の書き込みで 1.2% に上昇、
未使用領域で事なきを得る確率 10% を差っ引くとリビルド失敗率は
1.08% だな。

個人だとHDD4本構成(3d1p)ぐらい？。
ディスク使用率70%、エラー率は1/10^14 で週の書込量は総容量の
3% で計算。

スクラブなしだと任意の３本にエラーが乗っている確率が24%、
こちらも週１回スクラブ(TeraStationとかがこれぐらいの頻度？)
でほぼゼロに。
週に３%(0.72TB)書込で 0.72%、未使用領域で事なきをえる確率
30% 差っ引いてリビルド失敗率は 0.5% ぐらいか。

お前らいったん冷静になってスレタイ512回ほど音読しろ

みんなbtrfsの話してるとばかり思ってたのに
あ、個人の趣味でbtrfsでRAID1してます

まあまあ…
ファイルシステムを乗せるための
ファイルシステム/データストレージ関連技術として
RAIDとかLVMとかの話題もいいんじゃない？

専用スレも無いみたいだし(それまで過疎ってたし…)

>>945
Unrecoverable Read Error (URE)は言葉の通り「回復不可能な読み出しエラー」、
つまり読み出しの時点で新たに起きるエラーの話で
URE rate (URE率)というのは読み出しの総量に対してエラーが起きる確率
つまり厳密には事前の書き込みで起きる破損(破損セクタ)じゃないよ
適切に定期scrubすれば現実の故障のリスクを減らせると思われるのはその通りだけど
それ踏まえても「リビルド時のURE 」は無くせないって話

でも先の60%/6%で失敗って言ったのはカタログスペックの保守的な見積もり(のはずの)保証値から全容量でざっくり概算したもので
実際のHDDのエラー率はもっと低いだろって指摘する人もいるし
もっと楽観的に見れるんじゃねと言えばそれはそうだと思う

繰り返しになるけど俺が言いたいのは「"RAID5は" URE考えるとヤバイ」って所ね
RAID1はじめscrubなど適切な運用ありきの多くが
現実的じゃないとはまったく思ってないし言ってもないからね
ttps://www.enricobassetti.it/2022/03/raid5-ure-and-the-probability/

長々ほぼスレチ話しちゃったから無理やり話戻すけど
btrfsでRAID5だけは絶対やめとけ
地雷機能の地雷構成とか絶対死ぬでw
ttps://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices

ひとのコメントを根拠とか示さず貼られても…
RAID5ではこれこれの機能が理論的には必要だけど
linux mdはこれこれが実装されていないとか
具体的に書けばよいのに

え、まだ続けんのこの話？？？
どういう実装(ハードウェア/ソフトウェア)でもRAID5は原理的にクラッシュ時のwrite hole(データ/パリティの不整合)の時の問題があるから
電源周りなら例えばUPSで確実にセーフシャットダウン出来るとか
バッテリーバックアップ(キャッシュ)付きのハードウェアRAIDとかが推奨に近いレベルであるべきだし
ソフトウェアRAIDなら何かしらトランザクションログ付き(ZFSのRAIDZがこれ)になってるとか
それでも偶発的なクラッシュによる中断はあり得るとか
何にしても「安全な運用」はかなり難しいか
出来るとしても少なくともかなり上等な環境と管理者が要ると思いますけど

てかmdadm含め「RAID」全体だと厳密にはスレチなんじゃねーの？？？
Linux板のファイルシステム総合スレなんだからさあ
RAID機能の話ならbtrfsとかOpenZFSとかの話をするスレなんじゃないのか
んでbtrfsならまさにwrite hole問題を軽減する実装に乏しいから
RAID5(と6)は現状やめときって評価なんじゃないの？
なんか間違ったこと言ってる？

write holeはRAID1でも起こり得るのだが…
Disk1だけ書き込めてDisk0は書き込めない状況
両ディスクで内容が異なる

write holeあったとしてもbtrfsはRAID1でもチェックサムあるからスクラブで修正出来るんじゃないの？

RAID1でもwrite holeそのものは起こるけど
ミラーリングは単にどちらか片方のコピーが正しい可能性が高く
btrfsなら今あるメタデータとチェックサムだけでスクラブで十分に修正出来る
対して5/6はストライプ+パリティで仕組みが複雑なので
最悪アレイが丸ごとおじゃんになる可能性がある

>>951
> なんか間違ったこと言ってる？
「Btrfs のRAID-5は危険だから使うな」は間違いかな。

「どうして TeraStation や QNAP は RAID-5 で炎上していない
んだ」、「炎上しないために何をすれば良いんだ」、
「本当のリビルドの失敗率はどれくらいなんだ」、「ファイル
システムのジャーナリングがライトホールに対してどれだけ有効
か/無力か」あたりを突き詰めるのが正解じゃね？

なんか根拠で碌に精度も出せてないのにバッサリ「使うな」って
雑な結論ゴリゴリ押しつけてくるだけって感じる。

↑951じゃないけど横からちょっとだけ
少なくともQNAPのRAID5は「Btrfsの内蔵機能」での
RAID5じゃなくて、MD機能を使ったRAIDですのだ…
(最近のQNAPではさらにLVMのレイヤーも噛ませてた気も)

「Btrfsの」RAID5(RAID6も?)は、少なくとも
カーネル6.1とかの段階では、メンテナー自身が
危険だからデバッグ目的以外で使うなって言ってた

MDを使ったソフトウェアRAIDはもう枯れまくってて
自身の機能部分での安定性は実績がある…
けど拡張性や柔軟性は現在基準では比較でやはり厳しい感

これか？

Linux 6.2カーネルに含めるためにBtrfsの改善が提案されました RAID 5/6 実装での書き込みホールの問題を修正します。

https://ja.linuxadictos.com/Linux-6-2.html
https://en.linuxadictos.com/Linux-6-2.html


RAID5/6 の場合、ファイル システムはチェックサムを保存しません。

この場合、ファイル システムは読み取り-変更-書き込み (RMW) 操作を実行する必要があります。

開発者は、RMW 操作がこの操作を実行する前にブロックのチェックサムを検証し、必要に応じてデータ リカバリが書き込み後にチェックサム検証も実行するように変更を加えました。
残念ながら、不完全なフリンジ (RMW) が書き込まれる状況では、これによりチェックサムを計算するための追加のオーバーヘッドが発生しますが、信頼性が大幅に向上します。 RAID6 の場合、そのようなロジックはまだ準備ができていません。

今のbtrfs-progsでも作ると警告出るし
ドキュメントでも警告されててふつうに非推奨のままや

昔みたterra stationは、xfsだったな。
RAIDもmdなんじゃ無いかな？

最近出てきた20TオーバのHDDでRAID5とか組んだらリビルドが終わらんだろうな

SSDならリビルドどれだけ速くなるんだろうか
CPUが追いつかんか

フラッシュメモリの特性として読込みに比べて書込みは桁違いに遅い
各種キャッシュで表面化しないようにしているけど
全面書込みではフラッシュメモリの特性が露骨に出てくる

SSDの書き込みが遅くなるのはフラッシュメモリのせいではなくMLCとかQLCのせいでは？

SSD は書込寿命あるから不要な書き換えの多い RAID-5/6/Z1/Z2
あたりは非推奨みたいに言われてるんじゃなかったっけ？

「不要な書き換え」が多い？
具体的にはどのような書き換え？
不要ならなぜ実装されているわけ？

不要な書き換えについてはわからないけど、
RAIDとかファイルシステム直じゃない
抽象レイヤーを挟むと
だいたいtrimは実行できなくなる感じ

フラッシュメモリでは書き換えブロックが集中しやすくて
寿命の面では不利にはなりそう

>>965
すまない、この説の信奉者じゃないんで詳しくはないんだが...

ランダムライトで4KiB書き換えた場合でもパリティは全書き換えだから、
チャンクサイズが64KiBだと4KiB+64KiB 書き換えが必要。 (4KiB 17回分)
RAID-1 なら 4KiBx2 (2回分) で済む。

RAID-1 はシーケンシャルライトするだけで２倍書き込むから
書き込み回数でいうなら RAID-5 より多いじゃん、といえばそう
なんだがドライブ１本あたりの書込回数って意味だと RAID-5
の方が多くなるとかなんとか。

ファイルシステムのメタデータはランダムアクセスなんで昔から
メタデータについては RAID-5/6 は避けろとは言われているね。
とくに LustreFS や GPFS とか。
>>957 にもメタデータは RAID-1 にしろとある。
xfs も mkfs オプションでメタデータだけ別ブロックデバイスに
配置できるオプションが昔からあるが、そういえば使ったことないな。

ちゃんと元の論文なりきちんとした文献を読んだり理解していないようですね
下記wikiももっともらしく書いてありますが
https://wiki.archlinux.jp/index.php/RAID
RAID5の書込パフォーマンスが(n−1)Xで高速と書いてありますが大嘘ですよ
書込はストライプやストリップ境界と揃わない場合読込みが入り遅くなるのは常識
それをあえて書かないのは雑誌と同じで商業的にあえて触れていず不誠実です

>>968
んでそのストリップ境界でRMWする確率はどれくらいなんだい？
めったに起きないから(n-1)Xちかくで書き込むのを実測できるわけで。

論文なんてもはやトイレの紙にもならんもの読むんじゃなくて
一流企業のベンダーの資料に目を通したまえ。

SSDはコントローラーのメーカーによってかなり動きが違うよね
SSD全体を一般化して語るのはおかしいよ
1つのSSDで試しても他のメーカーでは違う結果が出るかもしれない

>>963
どゆこと？

SSDはHDDとは違ってKernelから認識しているデータ配置と実際の配置がまるで違うからな
それを改善するためにZNS SSDとかいうのが出てきてるけど

btrfsでSSD RAID10してるけど2年くらい運用してるけど
シリコンパワーとかいう半年で壊れるメーカーのせいで2度リビルドさせられた以外は特にトラブルなしだよ
安価なディスクを組み合わせて信頼性や性能を向上させるっていうRAIDの利点はSSDでは通用しないらしい

読み書きの仕組みも HDD と結構違うぞ

SSD の読み書きはページ単位(16KiB or 32KiB, 型番による)で
Trim(消去) はブロック単位(512KiB など, 型番による)

書き込み回数を均す (Wear Leveling) 目的もあるので一旦書き込んだら上書きしない
1bit でも書き換えたページは別ページに書き直し

再利用するにはガーベージコレクションで使用中のページを別ブロックに追い出してブロック内の全ページを未使用状態にしてからブロック単位で Trim
どうみてもデフラグ(略)

まあ SMR (瓦書き込み: 1bit書き換えで最悪ハードディスク８回転ぐらい？させて書き込む(瓦を敷きなおす)必要がある) よりかはわかりやすいが

そもそもSSDはストライピング系のRAIDレベルで
速度向上させるまでもなく、
元々実用上十分なアクセス速度がある気がしなくもない…
ベンチマークでの速度が目的なら何も言えないけど

素人ですまんが fstrim って定期的に実行したほうがいいのは今も昔も変わってないよね？

Trimの効果はファーム（メーカの方針）による
要するにモデルによって異なる
まあ週一くらいで実行すればいいんじゃない

いまはsystemdに組み込まれたりして勝手に動いてるよ

ファイルシステムからデバイスに対して未使用ブロックの報告をいつするか だからメーカの方針云々は間違いでは？

マウントオプションに discard を入れていれば fstrim 不要だけど rm する度に処理が走ってモタつくから週末あたりにまとめて fstrim しろって認識

次スレ
ファイルシステム総合スレ その21
ttps://mao.5ch.net/test/read.cgi/linux/1750553314/

>>979
btrfsにはdiscard=asyncというオプションがあってな……

>>981
なんと。 Btrfs は discard でももたつかないんですね

愚かな質問に答えてくれてサンクス
週一で fstrim を実行するようにしておきます (systemd は使ってないので cron で)

Apple Sparse Image Format(ASIF) というのもあるんだな。Linux/*BSD で使えないだろうけど。

Appleがどれだけ優秀なファイルシステムを開発しようとサーバーとして使えないんだから意味ないわな