[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
938(1): login:Penguin [] 06/17(火)12:57 ID:G5q8UCPD(5/8)
>>933
は事実と異なる内容を記述している
あるHDD/SSDでURE(回復不可能な読み取りエラー)が出たら
RAIDレベルによらず全HDD/SSD稼働中なら他のHDD/SSDのデータから復元できる
(要は1台故障と同じ(切り離して故障にするかは別問題でコントローラの設計))
HDD/SSD故障があるのならRAIDレベルによらず多重故障でデータ復元できない
RAID6は2点故障でも復元できるけど
939(1): login:Penguin [sage] 06/17(火)13:27 ID:lZRqBMI7(3/4)
現場的には6%はかなり盛り過ぎだと感じるわ。
RAID のチャンクサイズ考慮して計算されてないか、
スクラブとかSMART監視とかない前提？
940: login:Penguin [sage] 06/17(火)13:37 ID:1K0szjjx(1)
>>938
だから「リビルドがUREで失敗する確率は決して低くない」という話だって言ってるじゃん
冗長性のあるRAIDレベルで通常稼働時に単一の障害が訂正出来るのは当たり前じゃねーかw
>>939
あくまで「リビルド中にUREに遭遇する確率」をカタログスペックから単純計算(概算)した数字の話なので
もちろん実際の障害の可能性はもう少し前後し得るよ
改めて補足しとくけどUREはSMARTとかからわかる形で
明確に「故障」せずとも読み取り時に偶発的に起きる確率的現象で
だから市販製品のデータシートにもちゃんと書いてあるんだ(Non-recoverable errors per bits readの項とかその辺り)
もちろん業務用途ならHDD/SSDにしろRAIDカードにしろソフトウェアRAIDにしろ
ずっと上等で堅牢な構成を採用してる事が多いから
破滅的な結果に至る確率はぐっと低いよ
あくまで典型的には個人がRAID5やるシナリオだと致命的になりがちって話ね
https://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
https://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf
941: login:Penguin [] 06/17(火)13:51 ID:G5q8UCPD(6/8)
5分停止したら何億とか会社消滅ならRAIDでサービス継続は分かる
でも個人用途ではHDD故障して機能のバックアップで十分
データ書き戻しで半日くらい止まっても大丈夫
これらが大半
RAID不要だろって話
webや雑誌記事でのせられて使っているだけでしょ?
942: login:Penguin [] 06/17(火)13:52 ID:G5q8UCPD(7/8)
昨日のバックアップデータで許容ね
943: login:Penguin [sage] 06/17(火)14:22 ID:89jEObby(1)
linux板って個人と企業を混合して話をするからエスパー力を必要とされるね
944: login:Penguin [sage] 06/17(火)16:34 ID:TRstYWTQ(1)
>>934
3週間間隔でエラー補正かかる、は流石にディスクの方を疑おうよ…
945(1): login:Penguin [sage] 06/17(火)19:12 ID:lZRqBMI7(4/4)
以下チラ裏。
週１回スクラブ、週の書き込みが総容量の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% ぐらいか。
946: login:Penguin [sage] 06/17(火)19:17 ID:526FSu8J(1)
お前らいったん冷静になってスレタイ512回ほど音読しろ
947: login:Penguin [sage] 06/17(火)19:47 ID:YcGRWNVI(2/4)
みんなbtrfsの話してるとばかり思ってたのに
あ、個人の趣味でbtrfsでRAID1してます
948: login:Penguin [sage] 06/17(火)19:48 ID:0tWlbWzs(1)
まあまあ…
ファイルシステムを乗せるための
ファイルシステム/データストレージ関連技術として
RAIDとかLVMとかの話題もいいんじゃない？
専用スレも無いみたいだし(それまで過疎ってたし…)
949: login:Penguin [sage] 06/17(火)21:52 ID:YcGRWNVI(3/4)
>>945
Unrecoverable Read Error (URE)は言葉の通り「回復不可能な読み出しエラー」、
つまり読み出しの時点で新たに起きるエラーの話で
URE rate (URE率)というのは読み出しの総量に対してエラーが起きる確率
つまり厳密には事前の書き込みで起きる破損(破損セクタ)じゃないよ
適切に定期scrubすれば現実の故障のリスクを減らせると思われるのはその通りだけど
それ踏まえても「リビルド時のURE 」は無くせないって話
でも先の60%/6%で失敗って言ったのはカタログスペックの保守的な見積もり(のはずの)保証値から全容量でざっくり概算したもので
実際のHDDのエラー率はもっと低いだろって指摘する人もいるし
もっと楽観的に見れるんじゃねと言えばそれはそうだと思う
繰り返しになるけど俺が言いたいのは「"RAID5は" URE考えるとヤバイ」って所ね
RAID1はじめscrubなど適切な運用ありきの多くが
現実的じゃないとはまったく思ってないし言ってもないからね
https://www.enricobassetti.it/2022/03/raid5-ure-and-the-probability/
長々ほぼスレチ話しちゃったから無理やり話戻すけど
btrfsでRAID5だけは絶対やめとけ
地雷機能の地雷構成とか絶対死ぬでw
https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices
950: login:Penguin [sage] 06/17(火)23:13 ID:G5q8UCPD(8/8)
ひとのコメントを根拠とか示さず貼られても…
RAID5ではこれこれの機能が理論的には必要だけど
linux mdはこれこれが実装されていないとか
具体的に書けばよいのに
951(1): login:Penguin [sage] 06/17(火)23:54 ID:YcGRWNVI(4/4)
え、まだ続けんのこの話？？？
どういう実装(ハードウェア/ソフトウェア)でもRAID5は原理的にクラッシュ時のwrite hole(データ/パリティの不整合)の時の問題があるから
電源周りなら例えばUPSで確実にセーフシャットダウン出来るとか
バッテリーバックアップ(キャッシュ)付きのハードウェアRAIDとかが推奨に近いレベルであるべきだし
ソフトウェアRAIDなら何かしらトランザクションログ付き(ZFSのRAIDZがこれ)になってるとか
それでも偶発的なクラッシュによる中断はあり得るとか
何にしても「安全な運用」はかなり難しいか
出来るとしても少なくともかなり上等な環境と管理者が要ると思いますけど
てかmdadm含め「RAID」全体だと厳密にはスレチなんじゃねーの？？？
Linux板のファイルシステム総合スレなんだからさあ
RAID機能の話ならbtrfsとかOpenZFSとかの話をするスレなんじゃないのか
んでbtrfsならまさにwrite hole問題を軽減する実装に乏しいから
RAID5(と6)は現状やめときって評価なんじゃないの？
なんか間違ったこと言ってる？
952: login:Penguin [sage] 06/18(水)00:21 ID:kTzkFbG6(1)
write holeはRAID1でも起こり得るのだが…
Disk1だけ書き込めてDisk0は書き込めない状況
両ディスクで内容が異なる
953: login:Penguin [sage] 06/18(水)00:33 ID:CeuUJCLk(1)
write holeあったとしてもbtrfsはRAID1でもチェックサムあるからスクラブで修正出来るんじゃないの？
954: login:Penguin [sage] 06/18(水)00:44 ID:6FJRmKfA(1)
RAID1でもwrite holeそのものは起こるけど
ミラーリングは単にどちらか片方のコピーが正しい可能性が高く
btrfsなら今あるメタデータとチェックサムだけでスクラブで十分に修正出来る
対して5/6はストライプ+パリティで仕組みが複雑なので
最悪アレイが丸ごとおじゃんになる可能性がある
955: login:Penguin [sage] 06/18(水)10:37 ID:wvNgIh7z(1)
>>951
> なんか間違ったこと言ってる？
「Btrfs のRAID-5は危険だから使うな」は間違いかな。
「どうして TeraStation や QNAP は RAID-5 で炎上していない
んだ」、「炎上しないために何をすれば良いんだ」、
「本当のリビルドの失敗率はどれくらいなんだ」、「ファイル
システムのジャーナリングがライトホールに対してどれだけ有効
か/無力か」あたりを突き詰めるのが正解じゃね？
なんか根拠で碌に精度も出せてないのにバッサリ「使うな」って
雑な結論ゴリゴリ押しつけてくるだけって感じる。
956: login:Penguin [sage] 06/18(水)13:29 ID:f4q6cLid(1)
↑951じゃないけど横からちょっとだけ
少なくともQNAPのRAID5は「Btrfsの内蔵機能」での
RAID5じゃなくて、MD機能を使ったRAIDですのだ…
(最近のQNAPではさらにLVMのレイヤーも噛ませてた気も)
「Btrfsの」RAID5(RAID6も?)は、少なくとも
カーネル6.1とかの段階では、メンテナー自身が
危険だからデバッグ目的以外で使うなって言ってた
MDを使ったソフトウェアRAIDはもう枯れまくってて
自身の機能部分での安定性は実績がある…
けど拡張性や柔軟性は現在基準では比較でやはり厳しい感
957(1): login:Penguin [sage] 06/18(水)14:06 ID:K/MF2oNs(1)
これか？
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 の場合、そのようなロジックはまだ準備ができていません。
上下前次1-新書関写板覧索設栞歴
あと 45 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.018s