[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
963(1): login:Penguin [] 06/20(金)01:10 ID:eaZI5k8F(1)
SSDの書き込みが遅くなるのはフラッシュメモリのせいではなくMLCとかQLCのせいでは？
964: login:Penguin [sage] 06/20(金)09:14 ID:kjXcySV2(1/3)
SSD は書込寿命あるから不要な書き換えの多い RAID-5/6/Z1/Z2
あたりは非推奨みたいに言われてるんじゃなかったっけ？
965(1): login:Penguin [] 06/20(金)11:18 ID:qYS4FMam(2/3)
「不要な書き換え」が多い？
具体的にはどのような書き換え？
不要ならなぜ実装されているわけ？
966: login:Penguin [sage] 06/20(金)11:56 ID:Uag62jWA(1)
不要な書き換えについてはわからないけど、
RAIDとかファイルシステム直じゃない
抽象レイヤーを挟むと
だいたいtrimは実行できなくなる感じ
フラッシュメモリでは書き換えブロックが集中しやすくて
寿命の面では不利にはなりそう
967: login:Penguin [sage] 06/20(金)18:01 ID:kjXcySV2(2/3)
>>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): login:Penguin [] 06/20(金)20:34 ID:qYS4FMam(3/3)
ちゃんと元の論文なりきちんとした文献を読んだり理解していないようですね
下記wikiももっともらしく書いてありますが
https://wiki.archlinux.jp/index.php/RAID
RAID5の書込パフォーマンスが(n−1)Xで高速と書いてありますが大嘘ですよ
書込はストライプやストリップ境界と揃わない場合読込みが入り遅くなるのは常識
それをあえて書かないのは雑誌と同じで商業的にあえて触れていず不誠実です
969: login:Penguin [sage] 06/20(金)23:30 ID:kjXcySV2(3/3)
>>968
んでそのストリップ境界でRMWする確率はどれくらいなんだい？
めったに起きないから(n-1)Xちかくで書き込むのを実測できるわけで。
論文なんてもはやトイレの紙にもならんもの読むんじゃなくて
一流企業のベンダーの資料に目を通したまえ。
970: login:Penguin [] 06/21(土)00:20 ID:KlN9oYmI(1/2)
SSDはコントローラーのメーカーによってかなり動きが違うよね
SSD全体を一般化して語るのはおかしいよ
1つのSSDで試しても他のメーカーでは違う結果が出るかもしれない
971: login:Penguin [] 06/21(土)08:41 ID:3iENlu5H(1)
>>963
どゆこと？
972: login:Penguin [] 06/21(土)09:04 ID:KlN9oYmI(2/2)
SSDはHDDとは違ってKernelから認識しているデータ配置と実際の配置がまるで違うからな
それを改善するためにZNS SSDとかいうのが出てきてるけど
973: login:Penguin [sage] 06/21(土)09:56 ID:p0nxy9BL(1)
btrfsでSSD RAID10してるけど2年くらい運用してるけど
シリコンパワーとかいう半年で壊れるメーカーのせいで2度リビルドさせられた以外は特にトラブルなしだよ
安価なディスクを組み合わせて信頼性や性能を向上させるっていうRAIDの利点はSSDでは通用しないらしい
974: login:Penguin [sage] 06/21(土)12:11 ID:73DbppD8(1)
読み書きの仕組みも HDD と結構違うぞ
SSD の読み書きはページ単位(16KiB or 32KiB, 型番による)で
Trim(消去) はブロック単位(512KiB など, 型番による)
書き込み回数を均す (Wear Leveling) 目的もあるので一旦書き込んだら上書きしない
1bit でも書き換えたページは別ページに書き直し
再利用するにはガーベージコレクションで使用中のページを別ブロックに追い出してブロック内の全ページを未使用状態にしてからブロック単位で Trim
どうみてもデフラグ(略)
まあ SMR (瓦書き込み: 1bit書き換えで最悪ハードディスク８回転ぐらい？させて書き込む(瓦を敷きなおす)必要がある) よりかはわかりやすいが
975: login:Penguin [sage] 06/21(土)12:15 ID:U4z6kL4u(1)
そもそもSSDはストライピング系のRAIDレベルで
速度向上させるまでもなく、
元々実用上十分なアクセス速度がある気がしなくもない…
ベンチマークでの速度が目的なら何も言えないけど
976(1): login:Penguin [sage] 06/21(土)23:12 ID:EGQeHYc0(1)
素人ですまんが fstrim って定期的に実行したほうがいいのは今も昔も変わってないよね？
977: login:Penguin [sage] 06/22(日)02:57 ID:b/oVtT+X(1)
Trimの効果はファーム（メーカの方針）による
要するにモデルによって異なる
まあ週一くらいで実行すればいいんじゃない
978: login:Penguin [sage] 06/22(日)05:05 ID:11SdqEm/(1)
いまはsystemdに組み込まれたりして勝手に動いてるよ
979(1): login:Penguin [sage] 06/22(日)08:41 ID:A0LT32zn(1/3)
ファイルシステムからデバイスに対して未使用ブロックの報告をいつするか だからメーカの方針云々は間違いでは？
マウントオプションに discard を入れていれば fstrim 不要だけど rm する度に処理が走ってモタつくから週末あたりにまとめて fstrim しろって認識
980(1): login:Penguin [sage] 06/22(日)09:50 ID:A0LT32zn(2/3)
次スレ
ファイルシステム総合スレ その21
2chｽﾚ:linux
981(1): login:Penguin [sage] 06/22(日)09:53 ID:OD+5t1eX(1)
>>979
btrfsにはdiscard=asyncというオプションがあってな……
982: login:Penguin [sage] 06/22(日)10:06 ID:A0LT32zn(3/3)
>>981
なんと。 Btrfs は discard でももたつかないんですね
上下前次1-新書関写板覧索設栞歴
あと 20 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.010s