[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
951(1): 06/17(火)23:54 ID:YcGRWNVI(4/4) AAS
え、まだ続けんのこの話？？？
どういう実装(ハードウェア/ソフトウェア)でもRAID5は原理的にクラッシュ時のwrite hole(データ/パリティの不整合)の時の問題があるから
電源周りなら例えばUPSで確実にセーフシャットダウン出来るとか
バッテリーバックアップ(キャッシュ)付きのハードウェアRAIDとかが推奨に近いレベルであるべきだし
ソフトウェアRAIDなら何かしらトランザクションログ付き(ZFSのRAIDZがこれ)になってるとか
それでも偶発的なクラッシュによる中断はあり得るとか
何にしても「安全な運用」はかなり難しいか
出来るとしても少なくともかなり上等な環境と管理者が要ると思いますけど
てかmdadm含め「RAID」全体だと厳密にはスレチなんじゃねーの？？？
Linux板のファイルシステム総合スレなんだからさあ
RAID機能の話ならbtrfsとかOpenZFSとかの話をするスレなんじゃないのか
んでbtrfsならまさにwrite hole問題を軽減する実装に乏しいから
RAID5(と6)は現状やめときって評価なんじゃないの？
なんか間違ったこと言ってる？
952: 06/18(水)00:21 ID:kTzkFbG6(1) AAS
write holeはRAID1でも起こり得るのだが…
Disk1だけ書き込めてDisk0は書き込めない状況
両ディスクで内容が異なる
953: 06/18(水)00:33 ID:CeuUJCLk(1) AAS
write holeあったとしてもbtrfsはRAID1でもチェックサムあるからスクラブで修正出来るんじゃないの？
954: 06/18(水)00:44 ID:6FJRmKfA(1) AAS
RAID1でもwrite holeそのものは起こるけど
ミラーリングは単にどちらか片方のコピーが正しい可能性が高く
btrfsなら今あるメタデータとチェックサムだけでスクラブで十分に修正出来る
対して5/6はストライプ+パリティで仕組みが複雑なので
最悪アレイが丸ごとおじゃんになる可能性がある
955: 06/18(水)10:37 ID:wvNgIh7z(1) AAS
>>951
> なんか間違ったこと言ってる？
「Btrfs のRAID-5は危険だから使うな」は間違いかな。
「どうして TeraStation や QNAP は RAID-5 で炎上していない
んだ」、「炎上しないために何をすれば良いんだ」、
「本当のリビルドの失敗率はどれくらいなんだ」、「ファイル
システムのジャーナリングがライトホールに対してどれだけ有効
か/無力か」あたりを突き詰めるのが正解じゃね？
なんか根拠で碌に精度も出せてないのにバッサリ「使うな」って
雑な結論ゴリゴリ押しつけてくるだけって感じる。
956: 06/18(水)13:29 ID:f4q6cLid(1) AAS
↑951じゃないけど横からちょっとだけ
少なくともQNAPのRAID5は「Btrfsの内蔵機能」での
RAID5じゃなくて、MD機能を使ったRAIDですのだ…
(最近のQNAPではさらにLVMのレイヤーも噛ませてた気も)
「Btrfsの」RAID5(RAID6も?)は、少なくとも
カーネル6.1とかの段階では、メンテナー自身が
危険だからデバッグ目的以外で使うなって言ってた
MDを使ったソフトウェアRAIDはもう枯れまくってて
自身の機能部分での安定性は実績がある…
けど拡張性や柔軟性は現在基準では比較でやはり厳しい感
957(1): 06/18(水)14:06 ID:K/MF2oNs(1) AAS
これか？
Linux 6.2カーネルに含めるためにBtrfsの改善が提案されました RAID 5/6 実装での書き込みホールの問題を修正します。
外部ﾘﾝｸ[html]:ja.linuxadictos.com
外部ﾘﾝｸ[html]:en.linuxadictos.com
RAID5/6 の場合、ファイル システムはチェックサムを保存しません。
この場合、ファイル システムは読み取り-変更-書き込み (RMW) 操作を実行する必要があります。
開発者は、RMW 操作がこの操作を実行する前にブロックのチェックサムを検証し、必要に応じてデータ リカバリが書き込み後にチェックサム検証も実行するように変更を加えました。
残念ながら、不完全なフリンジ (RMW) が書き込まれる状況では、これによりチェックサムを計算するための追加のオーバーヘッドが発生しますが、信頼性が大幅に向上します。 RAID6 の場合、そのようなロジックはまだ準備ができていません。
958: 06/18(水)14:33 ID:mS/Jtlgs(1) AAS
今のbtrfs-progsでも作ると警告出るし
ドキュメントでも警告されててふつうに非推奨のままや
959: 06/19(木)12:07 ID:FZnGLgFp(1) AAS
昔みたterra stationは、xfsだったな。
RAIDもmdなんじゃ無いかな？
960: 06/19(木)22:46 ID:/5HUQadQ(1) AAS
最近出てきた20TオーバのHDDでRAID5とか組んだらリビルドが終わらんだろうな
961: 06/19(木)23:25 ID:DYz6LZHt(1) AAS
SSDならリビルドどれだけ速くなるんだろうか
CPUが追いつかんか
962: 06/20(金)00:46 ID:qYS4FMam(1/3) AAS
フラッシュメモリの特性として読込みに比べて書込みは桁違いに遅い
各種キャッシュで表面化しないようにしているけど
全面書込みではフラッシュメモリの特性が露骨に出てくる
963(1): 06/20(金)01:10 ID:eaZI5k8F(1) AAS
SSDの書き込みが遅くなるのはフラッシュメモリのせいではなくMLCとかQLCのせいでは？
964: 06/20(金)09:14 ID:kjXcySV2(1/3) AAS
SSD は書込寿命あるから不要な書き換えの多い RAID-5/6/Z1/Z2
あたりは非推奨みたいに言われてるんじゃなかったっけ？
965(1): 06/20(金)11:18 ID:qYS4FMam(2/3) AAS
「不要な書き換え」が多い？
具体的にはどのような書き換え？
不要ならなぜ実装されているわけ？
966: 06/20(金)11:56 ID:Uag62jWA(1) AAS
不要な書き換えについてはわからないけど、
RAIDとかファイルシステム直じゃない
抽象レイヤーを挟むと
だいたいtrimは実行できなくなる感じ
フラッシュメモリでは書き換えブロックが集中しやすくて
寿命の面では不利にはなりそう
967: 06/20(金)18:01 ID:kjXcySV2(2/3) AAS
>>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 オプションでメタデータだけ別ブロックデバイスに
配置できるオプションが昔からあるが、そういえば使ったことないな。
968(1): 06/20(金)20:34 ID:qYS4FMam(3/3) AAS
ちゃんと元の論文なりきちんとした文献を読んだり理解していないようですね
下記wikiももっともらしく書いてありますが
外部ﾘﾝｸ:wiki.archlinux.jp
RAID5の書込パフォーマンスが(n−1)Xで高速と書いてありますが大嘘ですよ
書込はストライプやストリップ境界と揃わない場合読込みが入り遅くなるのは常識
それをあえて書かないのは雑誌と同じで商業的にあえて触れていず不誠実です
969: 06/20(金)23:30 ID:kjXcySV2(3/3) AAS
>>968
んでそのストリップ境界でRMWする確率はどれくらいなんだい？
めったに起きないから(n-1)Xちかくで書き込むのを実測できるわけで。
論文なんてもはやトイレの紙にもならんもの読むんじゃなくて
一流企業のベンダーの資料に目を通したまえ。
970: 06/21(土)00:20 ID:KlN9oYmI(1/2) AAS
SSDはコントローラーのメーカーによってかなり動きが違うよね
SSD全体を一般化して語るのはおかしいよ
1つのSSDで試しても他のメーカーでは違う結果が出るかもしれない
971: 06/21(土)08:41 ID:3iENlu5H(1) AAS
>>963
どゆこと？
972: 06/21(土)09:04 ID:KlN9oYmI(2/2) AAS
SSDはHDDとは違ってKernelから認識しているデータ配置と実際の配置がまるで違うからな
それを改善するためにZNS SSDとかいうのが出てきてるけど
973: 06/21(土)09:56 ID:p0nxy9BL(1) AAS
btrfsでSSD RAID10してるけど2年くらい運用してるけど
シリコンパワーとかいう半年で壊れるメーカーのせいで2度リビルドさせられた以外は特にトラブルなしだよ
安価なディスクを組み合わせて信頼性や性能を向上させるっていうRAIDの利点はSSDでは通用しないらしい
974: 06/21(土)12:11 ID:73DbppD8(1) AAS
読み書きの仕組みも HDD と結構違うぞ
SSD の読み書きはページ単位(16KiB or 32KiB, 型番による)で
Trim(消去) はブロック単位(512KiB など, 型番による)
書き込み回数を均す (Wear Leveling) 目的もあるので一旦書き込んだら上書きしない
1bit でも書き換えたページは別ページに書き直し
再利用するにはガーベージコレクションで使用中のページを別ブロックに追い出してブロック内の全ページを未使用状態にしてからブロック単位で Trim
どうみてもデフラグ(略)
まあ SMR (瓦書き込み: 1bit書き換えで最悪ハードディスク８回転ぐらい？させて書き込む(瓦を敷きなおす)必要がある) よりかはわかりやすいが
975: 06/21(土)12:15 ID:U4z6kL4u(1) AAS
そもそもSSDはストライピング系のRAIDレベルで
速度向上させるまでもなく、
元々実用上十分なアクセス速度がある気がしなくもない…
ベンチマークでの速度が目的なら何も言えないけど
976(1): 06/21(土)23:12 ID:EGQeHYc0(1) AAS
素人ですまんが fstrim って定期的に実行したほうがいいのは今も昔も変わってないよね？
977: 06/22(日)02:57 ID:b/oVtT+X(1) AAS
Trimの効果はファーム（メーカの方針）による
要するにモデルによって異なる
まあ週一くらいで実行すればいいんじゃない
978: 06/22(日)05:05 ID:11SdqEm/(1) AAS
いまはsystemdに組み込まれたりして勝手に動いてるよ
979(1): 06/22(日)08:41 ID:A0LT32zn(1/3) AAS
ファイルシステムからデバイスに対して未使用ブロックの報告をいつするか だからメーカの方針云々は間違いでは？
マウントオプションに discard を入れていれば fstrim 不要だけど rm する度に処理が走ってモタつくから週末あたりにまとめて fstrim しろって認識
980(1): 06/22(日)09:50 ID:A0LT32zn(2/3) AAS
次スレ
ファイルシステム総合スレ その21
2chｽﾚ:linux
上下前次1-新書関写板覧索設栞歴
あと 22 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.022s