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

ファイルシステム総合スレその17 at LINUX

1021:login:Penguin
17/12/18 08:21:54.12 x84wA0wv.net
枯れてるかどうかはわからんけど
xfsのほうがはるこに歴史はあるが

1022:login:Penguin
17/12/18 11:20:01.45 GyMlMt5D.net
>>982です。
>>983-984
ext4ってまだ開発中だったんですか。すっかり枯れたものだと思いこんでました。
それどこか、xfsの方が歴史が長かったなんて。
CentOS 7ではxfsが標準になっているので、逆転現象ですね。
IMAPサーバの構築でメールファイルの管理だけをしたいなら、
使い慣れたCentOS 6で、ext4を使う方がいいかなあと思ってきました。

1023:login:Penguin
17/12/18 21:55:50.85 zF3vE5KP.net
ext4にしとけ
extundeleteできるのは便利やぞ

1024:login:Penguin
17/12/18 22:08:00.85 GyMlMt5D.net
>>986
xfsは復活できないそうですね。
メモリも食うらしいので、
はい。もう少し、CentOS6でいきます。

1025:login:Penguin
17/12/28 12:29:00.51 bgFTfYxx.net
SSDのような記録形式は、劣化してくるとコンデンサでいうリフレッシュみたいなことをしないと
あまり頻繁にアクセスしないデータはいつの間にか電荷？の自然消失で壊れると聞いたんですが
ZFSのスクラブはリフレッシュの代わりになりますか？

1026:login:Penguin
17/12/28 13:02:12.19 vYCrbjN4.net
そんなことしても気休めにしかならないからバックアップ取ったほうがいいぞ

1027:login:Penguin
17/12/28 13:18:13.61 fkEzUj9L.net
>>988
バックアップしたのを

1028:丸々リストアするのが一番負担の負担が少ない細かいファイルを１個１個同じSSD内で完全にコピー→上書き移動とかしてるとディレクトリのエントリ（ファイルの一覧）への書き込み回数がとんでもない事になる

1029:login:Penguin
17/12/28 13:18:59.35 fkEzUj9L.net
負担の負担とかｗ　SSDの負担

1030:login:Penguin
17/12/28 17:49:23.94 bgFTfYxx.net
ありです
やっぱりきちんとバックアップも取っておいた方が良いですか
定期的にddでディスクを丸ごとHDDに保存してみようと思います

1031:login:Penguin
17/12/28 18:25:04.32 W1FLaU/H.net
SSDも劣化対策にRAIDにしておくべきだよね

1032:login:Penguin
17/12/28 18:39:00.12 fkEzUj9L.net
zfsとかReFSみたいなのなら劣化には有効なんだけど、従来のFSじゃ無理
だからデータ化け対策にMSまでもがわざわざ今頃になってReFSとかし始めてる訳で
3DMLCTLCのエラー訂正がどうなるかわからんけど、少なくとも寿命が来たUSBメモリに
ソフトウェアRAID組んでext4辺りで適当なでかいzipとか放り込んでしばらく放っておいた後、
（フラッシュの類の寿命って読み書きできないじゃなくて、
　データを保持できる時間が短くなる、だから待つのが重要）
データレベルでのエラーが検出できないから、エラーが起きたり起きなかったりする
ソフトウェアRAIDだけじゃなくて、ハードウェアRAIDも同じ
あれは律儀に両方の物理ドライブから読み込んで、両方のセクタの内容を比較とかしてない
（ハードウェアRAID0+1だと、先ず間違いなく片方からしか読んでないし、
　普通のミラーリングでも定期的に読み出す物理ドライブを切り替えて寿命を延ばそうとしてる）
Win10の記憶域プールの類も同じで、プールから作った論理ドライブにNTFS切ると同じ問題が起きる
RAIDはヘッドとかモータとかコントローラが死んだ時には止まらず動き続けてくれたり、
片方のデータで助けてくれたりはしてくれるけど、ECCかファイルシステムのどっちかが
データの正当性を検証し続けてくれない環境だと、運用中のデータ化けには無力（特にSSD）

1033:login:Penguin
17/12/28 18:56:15.30 aFTO9rA1.net
つまりエンプラSSDは期違いってこと？

1034:login:Penguin
17/12/28 19:25:06.39 NbmI0QOw.net
HDD も SSD も同じことだが、
RAID で DISK故障を発見したとき、他の DISK のデータが一部消えてたという事態は避けなければいけない。
そのために、全データを定期的に read　することが重要。アクセスすることによって訂正可能な範囲の劣化は修整される。
ダメならダメでデータが消えたことが発見できて RAID 使ってたら修正も可能。
コピーオンライトなFSは、GC もあるし、そういう機能を持ってると思うけれども、詳細は知らない。

1035:login:Penguin
17/12/28 19:25:16.21 fkEzUj9L.net
鯖向けのSSDでも、暗号化の類の保護はあっても、正当性の保証って意味での保護は滅多にない筈
（ちょっと考えればわかる）だからSLCとかで物理的な耐久で耐えようとしてるっしょ
で、わざわざ電源断の保護とか謳ってたりするとこからわかると思うけど、
一般的なSSDの多くは書き込み中に電源落とすと、内部でのイレース→書き込みで、
イレース直後に力尽きた時はセクタの内容がオール０とかになる
物理的な書き込みの順番を守ってないジャーナリングだと、
下手するとディレクトリエントリぶっ壊れて、ディレクトリ内のファイルの一部か全部ロストする
鯖向けの3Dは知らん

1036:login:Penguin
17/12/28 20:36:57.08 W1FLaU/H.net
複数SSD + ZFS + 定期scrub でいい？

1037:login:Penguin
17/12/28 23:22:58.51 1cm7+jyT.net
SSDは記憶場所の再配置も自動でやっているのでscrubなんて無価値だよ

1038:login:Penguin
17/12/28 23:27:37.88 Q2KhtiDj.net
ヾ(ﾟωﾟ)ﾉﾞ

1039:1001

1040:Over 1000 Thread.net

1041:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています