トップページ⇒linux
983コメント323KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin2013/03/15(金) 11:51:55.78ID:O3XCXQaz
●前スレ ファイルシステム総合スレ その15
http://engawa.2ch.net/test/read.cgi/linux/1341012960/l50
●関連スレ
ジャーナリングファイルシステム
http://toro.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://toro.2ch.net/test/read.cgi/unix/1337411922/
FS関連スレ
http://kohada.2ch.net/test/read.cgi/os/1137387538/l50
過去スレ、関連リンクは >>2-10 あたりで。
0421login:Penguin2013/10/19(土) 23:45:24.40ID:LBGng1/x
>>420
いる。少なくとも開発者は使ってんだろ。
0422login:Penguin2013/10/19(土) 23:47:23.01ID:xoeGYH0+
>>419
何回かにレスを分けてたので自分でもどこまで話したかわからなくなっていました。

結局dirCをzfsプールとzfs2プールにわけようと思うとmhddfsを使うほかないですよね？

そもそもmhddfsではなくシンボリックリンクが勧められる理由は何なのでしょうか。
手軽なのは確かにそうなのですが、ファイルパスが変わるとすべてのリンクを作りなおす必要があったり、
リンクファイルをコピーする際に、アプリによってリンク先の実体をコピーするものと
リンクファイル自体をコピーするものでまちまちなためmhddfsのほうが便利だと思っていたんですが
0423login:Penguin2013/10/20(日) 00:01:33.25ID:gTxMqX1I
簡単にいうとそんな貧乏くさいことは普通はしない
ストレージの大事さを理解してればコストは惜しまないと思うよ
0424login:Penguin2013/10/20(日) 00:49:58.77ID:fYTyHLf/
後付けの条件をどんどん出してくる馬鹿には氏ねじゃなくて死ねとしか言いようがない。
0425login:Penguin2013/10/20(日) 03:14:43.76ID:LybDE0D6
イマイチ何がポイントになってるのか分からない俺がいる
何でmhddfsからいきなりシンボリックリンクの話に飛ぶんだろうか
0426login:Penguin2013/10/20(日) 09:32:16.08ID:lUo3Q4yG
>>403 mhddfsとaufsとunionfsどれがいい？
>>407 その目的ならmhddfsがいい
>>408 じゃmhddfs使います

まとめるとこういう事
他はノイズ
0427login:Penguin2013/10/20(日) 09:55:29.72ID:dkuoGXU6
そもそも、こいつのお大事なバッチとやらを書き換えれば、何の問題も無いんだろ？
あと、mhddfsとやらが実際の所どの程度信用できるかは知らんが、少なくとも、
・性能が低下する
・元のディスクが一杯になるまで追加したディスクには書き込まない
んだろ？
もしかしてこいつの中では「片方のディスクが壊れても、半分のファイルは生き残る」
事になってるのかも知れんが、それは両方が一杯になった時だけで、元のディスク
の方が古い＝壊れるのも先なんだから、今の所殆ど全てのファイルを失う可能性の方が
高いだろ。その時にはバックアップがある！ってのなら、そもそもzfsでもいい話で

貧乏性でどうしても古いディクも使いたいってなら、
　4TBと2TBか3TBと1TBのディスクとJBOD出来るカードを買うなりなんなりで入手
→ 新しいディスクの大きい方で zpool create して autoexpand=true
→ zpool attach → 古いディスクを detach → 新しいディスクの小さい方と古い
ディスクで JBOD組む → attach とかするかな？

つか、自分なら2TBx4とかでraid-z2するだろうけど
0428login:Penguin2013/10/20(日) 09:58:51.19ID:dkuoGXU6
おっと、

×そもそもzfsでもいい話
○そもそもzfsでストライプすりゃいい話
0429login:Penguin2013/10/20(日) 11:10:41.88ID:C/3bPKFZ
>>427
おまえこの前の高飛車勘違い君だろ。

>そもそも、こいつのお大事なバッチとやらを書き換えれば、何の問題も無いんだろ？
それがしたくないからって質問してるのにお門違いもいいとこ

>あと、mhddfsとやらが実際の所どの程度信用できるかは知らんが
知らんならえらそうに話すな。
性能測定まではしてないが次のディスクに書き込み始めるまでの容量は決めれる

>もしかしてこいつの中では「片方のディスクが壊れても、半分のファイルは生き残る」
>事になってるのかも知れんが、それは両方が一杯になった時だけ
もう無茶苦茶。片方のディスクが壊れても当然生きてる方に書き込まれたデータは生き残る。
両方じゃなくて片方と言いたいんだろうが次ディスクに書き込む容量は変えられるからそれも間違ってる。

>古い＝壊れるのも先なんだから、今の所殆ど全てのファイルを失う可能性の方が
>高いだろ。その時にはバックアップがある！ってのなら、そもそもzfsでもいい話
まず古いHDDが壊れたら殆ど全てのファイﾙを失うっていう前提が意味不明。
どういうファイルを管理してるかは知らんが新しいデータが生きてることは大きいだろ。

>つか、自分なら2TBx4とかでraid-z2するだろうけど
>>単品HDDのzfsを拡張したいのですがRAIDは怖いし、小回りがきかないので避けたいです。
こう言ってるやつにRAIDを勧める意味がわからない。
将来また足すかもとか言ってるやつが一回RAIDZ2なんて組んだらディスク1本だけ足すとかができないだろうに。
0430login:Penguin2013/10/20(日) 11:31:51.12ID:dQajVw2K
まともに質問もできない日本語のおかしなゴミクズ質問者はスルーすべし
デキる自分を主張したくてクズでもかまいたがるゴミクズ回答者はくたばれ
0431login:Penguin2013/10/20(日) 19:29:27.08ID:o0GJpDC3
ストライピングがイヤだという部分だけは同意する。
俺のディスクは全てRAID1。
0432login:Penguin2013/10/20(日) 20:50:51.47ID:C/3bPKFZ
zfs使ってるような人は元々趣味でRAID組んでるような人が多いから意見が偏ってるんだよなぁ。

企業と違って個人ではファイルサーバが一時的に停止しても問題ないし
コスト度外視で考えてもそこまでRAIDが必要ってわけでもないと思うんだけどな。

確かにzfsの機能をフル活用するならガンガンHDD繋ぐほうがいいんだろうけど
・仮に死んだときにデータが全て飛ぶ上に復旧も絶望的
・HDDをちょっと別PCに繋ぎたいときもHDD4個も5個も運ばないといけない。
・RAIDZならHDDを1個追加みたいなことができない。
・RAID1の場合も増設時は同容量のHDDを2つ用意する必要がある
(HDDだけならともかくsata端子が足りなくなってきてポートマルチプライヤ買うはめになったりする)

スナップショット、cow、圧縮、チェックサムが便利だからzfs使ってるけど
raid嫌いな人のためにもストライプ切れるようにならないもんかね。
というかマイナーなところ探せばそういうFSもありそうだけど人柱怖い
0433login:Penguin2013/10/20(日) 21:40:46.40ID:jf7+doXb
>>432
＞zfs使ってるような人は元々趣味でRAID組んでるような人が多いから意見が偏ってるんだよなぁ。
それを偏見って言うんだよ。
そんな事言う奴の話なんて、誰も聞かねーよ。

みんな、使える道具の中で運用考えてんだよ。
RAID嫌いな奴はそもそも、そういう運用前提で、
ちゃんとHDDを使い分けてるだけだろ？
0434login:Penguin2013/10/20(日) 21:45:38.92ID:2jbbvIlL
>>432
btrfsが安定したらご期待にそえるんじゃないの？
たしか、一応現時点でも冗長化止めたりストライピングしたり変更できたはずでは。
0435login:Penguin2013/10/20(日) 21:48:50.72ID:pWnCpXI6
安定してから言ってくれ
0436login:Penguin2013/10/20(日) 23:47:51.68ID:OSIxSIqR
これからのファイルシステムに欲しい機能は、データの保護の強化、データの圧縮に
よるメディアの有効利用、SSD+HDDの連携と思っています。

今使えるファイルシステムとしては、ZFS（Native Linux）しかLinuxでの
選択肢はありませんが、今後の開発の可能性も含めて、ZFS以外で良さげなものが
あれば、是非教えて下さい。
0437login:Penguin2013/10/21(月) 16:40:47.76ID:aVpL83gh
>432

RAID0 とか concat-disk が嫌いという人がいてもいいと思う

でもそれなら「HDD追加して容量拡張したい」みたいなことは
死んでもいうなよってことじゃないのかな

# アスペっぽい書き込みはスルーして読んでないんだがｗ
0438login:Penguin2013/10/21(月) 18:40:53.54ID:X9lixWj/
趣味だの偏ってるだので他人を罵ってる奴が、「嫌い」とか、キ印としか思えん
0439login:Penguin2013/10/21(月) 20:13:46.61ID:WVTks6VH
>>406
マウントはできるようなのでやはりどこかがおかしいみたいです…。

mint ~ # mkdir /home/archive
mint ~ # zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 230K 58.6G 31K /data
data/archive 59K 58.6G 31K /data/archive
data/archive@test 28K - 31K -
mint ~ # mount -t zfs data/archive@test /home/archive
mint ~ # ls -la /home/archive
total 8
drwxr-xr-x 3 root mint 4 10月 16 20:12 .
drwxr-xr-x 5 root root 4096 10月 17 16:10 ..
-rw-r--r-- 1 root root 0 10月 16 20:12 a
drwxr-xr-x 2 root root 2 10月 16 20:12 test
0440login:Penguin2013/10/21(月) 22:40:36.45ID:CUJNcbU/
よもやID:av8klvMNよりヤバイのが来るとはな。
0441login:Penguin2013/10/21(月) 23:13:54.39ID:51o6NMnx
てか、単発多すぎだろ。
>>403以降アスペのアンチRAIDと過剰反応RAID信者の二人が自演合戦してるんじゃないかとすら思えてくる
0442login:Penguin2013/10/22(火) 00:16:52.43ID:MHRqDCi8
そんな１日に何回もレスするようなスレじゃないんで
結果的に単発IDになる。
0443login:Penguin2013/10/23(水) 19:43:08.24ID:aaYlhJpG
リカバリーレコードみたいな少し容量は増えるけど数%の破損なら補修できるような
都合のいい機能を標準装備したファイルシステムってないですか？

もしくはツールでそういうことが可能なら教えてください。
ツールの場合は圧縮ファイルのような形式ではなく
rrファイルを外部出力してどんなファイルにも使えるようなものが理想です。
0444login:Penguin2013/10/23(水) 19:57:22.63ID:19+PbIit
ファイルシステムではないけどrrの代わりなら
一応par2ってのがある
計算にめっちゃ時間かかるけどpar2bbならマルチコア対応してる
0445login:Penguin2013/10/23(水) 22:06:41.15ID:zlI5LHZK
zfsってプールの破損でなくファイルの破損ならcopiesなんかで冗長設定してなくても
チェックサムをもとにある程度回復できると思ってたんだけど違ったっけ？
探してみたけど書いてたページが見つからない。
普通に考えたらチェックサムをもとに回復って無理な気がしてきた。
0446login:Penguin2013/10/23(水) 23:11:22.82ID:w+iPLHYC
>>445
チェックサムでは回復は無理っすよ
0447login:Penguin2013/10/23(水) 23:21:36.13ID:zlI5LHZK
>>446
やっぱそうなのか。
他のFSに比べてzfsは接続不良なんかでのファイル破損がほとんどないとか、
1ブロックの破損なら自前で復旧できるみたいなのを見て安心した記憶があったんだが。
リカバリレコードなんかなくてもzfsでよくね？って思って見てたけど全然大丈夫じゃなかったんだな
0448login:Penguin2013/10/23(水) 23:56:23.53ID:IL5Wv5QQ
むしろチェックサムによって明確に壊れてることがわかるので見かけ上他のFSよりバンバンエラーが出る気がするｗ
>>443を見て思ったんだけど、単体HDDのパーティションを8分割くらいしてRAIDZ組むとか頭の悪いことしたらチェックサムエラー修復できるんだろうか。
0449login:Penguin2013/10/24(木) 00:16:03.31ID:yLEZ2bPz
checksumで修復できるのはビット化けみたいなものでしょ?
セクタ・ブロックが死ぬようなのは「大規模」なデータ損失で
それは RAID-Z なりのバックアップデータがなきゃ無理でしょ
0450login:Penguin2013/10/24(木) 00:28:12.11ID:IdBRDw4P
>>449
逆に言うとビット化け程度なら冗長設定してなくてもチェックサムだけで修復できるってこと？
HDDでビット化けってあんまり聞かない気がするけど
0451login:Penguin2013/10/24(木) 00:49:29.11ID:GDX/eWS5
ハミングコード
0452login:Penguin2013/10/24(木) 01:09:18.52ID:ssDUuLUa
HDD自体がECC使ってるしエラー検出とエラー訂正は同じじゃない
0453login:Penguin2013/10/24(木) 22:55:18.82ID:XS30xXcy
zfsのファイルシステムの作成ですが以下のようなことをしたいのですが方法はあるでしょうか。

①ディレクトリをまたいでファイルシステムの作成
zpool create zpool
zfs create zpool/a
mkdir /zpool/a/b
zfs create zpool/a/b/c <- bのファイルシステムは不要だがcのスナップショットを取りたい

②再帰的なロールバック
zpool create zpool
zfs create zpool/a
zfs create zpool/b
zfs snapshot -r zpool@1
zfs rollback zpool@1 <- a、bも含めて再帰的にロールバックしたい

2つめの場合は/zpool/a、/zpool/bをディレクトリにしてしまえば特に問題ないのですが、
ファイルシステムを作成せずにプールだけで運用ってあまり聞きませんが何か問題ありますか？
問題あるならファイルシステムをひとつ余計に作ってマウントポイントだけ変えようと思います。
0454login:Penguin2013/10/25(金) 04:11:16.80ID:tjxFsdIi
>>453
①
できないしできる必要がわからん。
bが本当に要らんならまずディレクトリとして要らない（zpool/cで良い）しそうじゃないならファイルシステムじゃダメな理由もわからん。
bのスナップショットが要らないにしても-r無しでaとcそれぞれで取ればいいだけだし。
②
できないんだよなぁ・・・rollback -rが別のオプション（最新より前のスナップショットにロールバック）になっちゃってるから。
多分手動かスクリプト書くかする必要があるんじゃ？

＞ファイルシステムを作成せずにプールだけで運用ってあまり聞きませんが何か問題ありますか？
send/recvが若干めんどくさくなるからプールのルートには何も置きたくはないね。
書いてるとおりルートはmountpoint=noneにして1個余計に作った方が楽かもね。
0455login:Penguin2013/10/25(金) 10:55:55.11ID:ugDlUU2T
>450
> HDDでビット化けってあんまり聞かない気がするけど

だって貴方は化けてても気づかないでしょ?
0456login:Penguin2013/10/25(金) 11:16:18.46ID:9rFB6ubH
>>455
心のビットなら分かるさ。Trueだろ？
0457login:Penguin2013/10/25(金) 12:25:31.20ID:0FwEouQp
False!
0458login:Penguin2013/10/25(金) 19:34:58.72ID:JffNeFET
Null
0459login:Penguin2013/10/25(金) 20:14:24.86ID:c/l0CUx/
>>454
①具体的に言うと下のような構成になっていて
backupやwin、macの下にはファイルがない状態です。

zpool/bakup/win/sys
zpool/bakup/win/data
zpool/bakup/mac/sys
zpool/bakup/mac/data
zpool/doc/～～～
zpool/share/～～～

特にファイルシステムであっても問題ないですがzfs listしたときに邪魔なのでもし方法があればと思っていました。
こういう場合みなさん特に気にせずファイルシステムを作ってるんでしょうか。
それとも下みたいな感じで最低限のファイルシステムを作ってマウントポイントを変更してるんでしょうか。
zfs set mountpoint=/zpool/bakup/win/sys zpool/win_sys
zfs set mountpoint=/zpool/bakup/win/data zpool/win_data
～省略～

将来的にファイルシステムが増え過ぎるのが面倒なのか、
zfsの構成とファイル構成が違ってくるほうが面倒なのか判断に迷うところです。
0460login:Penguin2013/10/26(土) 14:50:26.40ID:2B//8yQz
組み込みでFRomにjffs2ファイルシステムが乗ってるって話の場合
アプリは普通にファイルを作って書いたり読んだり消したり出来ると
思っていいですか？
0461login:Penguin2013/11/01(金) 18:02:19.20ID:OHi4c+6U
vxfs最強
0462login:Penguin2013/11/01(金) 22:35:43.34ID:/Bn0q+0Y
それ全角２５６文字のファイル名つけられるの？
0463login:Penguin2013/11/01(金) 22:37:29.10ID:A5V09kZl
全角をどんなエンコードで書き込むかによって違ってくる。
0464login:Penguin2013/11/02(土) 11:32:50.85ID:887lFvrv
皆様の知恵を拝借致します。

# ls -al /var/
drwxr-xr-x. 29 root root 100737024 Nov 2 10:38 log/

/var/log にlsをすると暫くたってからリストが表示されるのですがこれをシンプルに
縮退させる方法はありますでしょうか？

FSシステムはext3。肥大の原因となったファイル群は整理済みです。
0465login:Penguin2013/11/02(土) 12:06:22.83ID:ghHlEbPC
こいつはてーへんだ！
0466login:Penguin2013/11/02(土) 13:05:17.69ID:T2Oqcsfn
縮退の意味が分からん
var/logの中のファイルを削除して整理したいのか
lsの表示を早くしたいだけなのか
前者ならlogrotateとか使えと思うし後者ならls -fで頑張れとしか
0467login:Penguin2013/11/02(土) 13:23:20.43ID:2VosL/Ps
でかくなったディレクトリを小さくしたいという意味では?
ディレクトリってtruncateできるのかね?
0468login:Penguin2013/11/02(土) 13:40:42.65ID:d2Ccv1+/
dir_index使ってなきゃe2fsck -Dで縮むが
0469login:Penguin2013/11/02(土) 13:46:27.00ID:ojzZMU2F
最悪、
mkdir /a; mv /var/* /a; rmdir /var; mkdir /var; mv /a/* /var; rmdir /a
くらいで縮むと思うけど、副作用があっても知らん
0470login:Penguin2013/11/02(土) 13:48:24.95ID:ojzZMU2F
あぁ、/var じゃなく /var/log か
0471login:Penguin2013/11/02(土) 15:59:06.01ID:ghHlEbPC
いつもはディレクトリ作り直しているが /var/log
は CD ブートしないと出来ないよな。
0472login:Penguin2013/11/02(土) 20:53:36.83ID:KMMmRexE
シングルユーザーで立ち上げてもできなかったっけ？
0473login:Penguin2013/11/02(土) 22:19:21.19ID:ghHlEbPC
結論
・停止可能
　シングルユーザモードで起動するか別デバイスから起動し
　　e2fsck -D
　　or ディレクトリ再作成
・停止不可
　修正不可
0474login:Penguin2013/11/03(日) 19:39:59.63ID:EIQFhcTZ
/var/logを一時的にtmpfsにしてディレクトリ作り直したら？
04754642013/11/04(月) 15:44:24.92ID:tM1Wm+fs
皆様の温かいご意見に感謝申し上げます。
なくなくシングルユーザーモードで再起動して、e2fsck -D /dev/sda5 を実行して見ました。
⇒　縮退せず
ファイルシステムの再作成となりました。UUIDなどみのがしたので、デバイスエントリをマウントするように
変更して再起動したところ万事うまく行ったようです。

ご協力に感謝致します。
0476login:Penguin2013/11/04(月) 16:52:10.36ID:kzjwQk+Y
dir_index使ってたら縮まないんじゃないか。もっとも使ってたら遅くならないけど。
0477login:Penguin2013/11/04(月) 18:55:05.59ID:/vrbWrDE
昔から言われちゃいるがなんでやらんのだろな
http://pc8.2ch.net/test/read.cgi/linux/1101495293/759n-
ttp://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/threads.html#06569

>>476
>>464
0478login:Penguin2013/11/04(月) 21:15:50.05ID:Mc4mH5/X
こういうの「縮退」って言うもんなん?
0479login:Penguin2013/11/04(月) 22:05:16.00ID:R2gPhWNm
言わないと思う
0480login:Penguin2013/11/05(火) 01:08:56.63ID:x5EwXLLD
なんていうの？
0481login:Penguin2013/11/05(火) 18:22:50.90ID:V9FjLC3k
縮小でいいんじゃね
0482login:Penguin2013/11/05(火) 23:27:26.01ID:XqLkhYZK
計算機分野での縮退はフェイルソフトの意味で使われてるのが普通じゃね？
だもんで資源割当の最適化を指して使うには不適切じゃないかと

一般的にはshrinkでいいだろうから縮めるとか縮小あたりか
e2fsckの-Dオプションはディレクトリの最適化と称してる
0483login:Penguin2013/11/06(水) 19:24:45.14ID:rtQrlBIK
「フェイルソフト」って何？
0484login:Penguin2013/11/06(水) 19:33:01.25ID:hbMRSS5A
障害部分を切り離してシステム全体は軟着陸させること
0485login:Penguin2013/11/06(水) 19:55:47.73ID:nonnr+x1
>>483
ぐぐればすぐ出てくるよ。
0486login:Penguin2013/11/06(水) 20:05:40.94ID:s8Xkx+wT
いわゆるガーベージコレクションではないか。
0487login:Penguin2013/11/15(金) 11:42:42.03ID:9hTtO7jh
zfsってどの程度安定してるっぽい？
Linux系じゃなくてUnix系使った方が良いのかな？
突然データ吹っ飛んだりしない？

データ保管庫としてどの程度使えるのか聞きたい。
0488login:Penguin2013/11/15(金) 12:07:52.44ID:VKakjuP/
>>487
重複排除しなければ安定してる
0489login:Penguin2013/11/16(土) 13:32:35.81ID:cecGacoq
だれかbtrfs常用してる?
0490login:Penguin2013/11/16(土) 13:33:41.66ID:sra3+D4d
してるよ
0491login:Penguin2013/11/16(土) 19:08:08.57ID:klODC6Fw
緑3TBの20台でVMの共有ストレージに
してるけど、何ら問題ないよー

UPSと箱と電源に拘ってみては？
0492login:Penguin2013/11/16(土) 21:36:07.83ID:PUTOFxx6
まぁ、緑の真の恐怖は、１台イカれると周り中を道連れにして死ぬ点に有るんだがな
0493login:Penguin2013/11/16(土) 21:44:26.25ID:4Z3n+n2w
どうやって道連れにすんの？
0494login:Penguin2013/11/16(土) 22:08:59.61ID:PUTOFxx6
さてなぁ。リビルド時の高負荷で死ぬんだと思うが
0495login:Penguin2013/11/17(日) 00:25:14.43ID:O40qf6mF
アホじゃねーの
0496login:Penguin2013/11/17(日) 09:28:09.85ID:CRGzRdxz
和露多
0497login:Penguin2013/11/17(日) 09:49:24.20ID:a+DN6O1g
まぁ試してみればいいよ
安物NASメーカーのユーザーフォーラムとか読めば、それなりに一般的な現象だと分かると思うけど
0498login:Penguin2013/11/18(月) 01:02:31.08ID:I9FkgyOR
あー、リビルド時に電圧が揺れて、それで死ぬHDDとかありそうかも
0499login:Penguin2013/11/18(月) 15:13:11.08ID:9uyno7vf
>498

ナニソレ… 詰んでるじゃん
0500login:Penguin2013/11/18(月) 22:51:33.49ID:bDDNz1pj
>>498
ダメな電源使ってるとあり得るかもね
0501login:Penguin2013/11/19(火) 00:15:04.51ID:P8aDRHP+
安物NAS -> ダメ電源 -> リビルド時にHDD大量死

すじが通ってるっていうか、確かにありそう…
0502login:Penguin2013/11/19(火) 05:14:21.58ID:VUnJga0a
HDD 一括購入で RAID → 同ロット品を同じ条件で酷使 → 大体同じ時期に死亡
ってのは考えにくいんだろか？
0503login:Penguin2013/11/19(火) 05:20:37.26ID:dN6/7hdo
それはよく聞く話だね信憑性があるかどうか分からんけど
ユーザーフォーラムをみれば～と言ってるけどちゃんとしたデータでもあるの？
0504login:Penguin2013/11/19(火) 07:49:39.88ID:g05Kpkbk
蛸足状態で、電圧足りないだけだったりして。
0505login:Penguin2013/11/19(火) 11:58:29.64ID:OcMnYX9e
RAIDがリビルド中に死ぬ主な理由は、patrol readあるいはdata scrubbingを適切に行っていないから。
そのせいでリビルド中にエラーが見つかってmultiple faultで死ぬ。
0506login:Penguin2013/11/19(火) 13:08:37.83ID:jE8BP7f7
ハードウェアRAIDなら、RAIDカードの設定でauto verifyはonにするのが必須
0507login:Penguin2013/11/19(火) 13:52:07.70ID:DJml48id
mdでそういう設定みたいのある？
0508login:Penguin2013/11/19(火) 14:24:08.74ID:nsGqYGMa
>>507
raid-checkとか？
ただSMART値を監視するのと大差はないと思う。
0509login:Penguin2013/11/20(水) 01:34:46.12ID:cTOAfPI0
>>507
echo check > /sys/block/mdX/md/sync_actionをcronで定期実行
0510login:Penguin2013/11/20(水) 10:31:45.53ID:JFflcn2G
mdadmに定期同期チェックする機能なかったっけ？
0511login:Penguin2013/11/20(水) 14:50:25.16ID:rmMhU9tO
でも RAID1, RAID5 だとHDDのセクタエラーみたいな
「エラー出た」とハッキリしているものは修復できるけど
黙って化けられたら，どちらが正解か判断できないよね?

RAID6 なら多数決作戦もいけそうだけど．

結局 ZFS みたいな checksum をどこかに持ってないと
サイレントエラーには勝てないんじゃない?
0512login:Penguin2013/11/20(水) 19:23:39.66ID:bY8G6Pf2
ZFS の開発がホットだった頃と違って、今の HDD は誤り訂正符号で
データを書き込むから、サイレントエラーはあんまり考えなくても良い気がする。
0513login:Penguin2013/11/20(水) 20:41:37.29ID:wZCapg96
ZFSって2004年からじゃん。
訂正符号はSNが良くなるのと同じだからね。
製品の目標BERって変わってないと思うよ。故障率も
CRCみたいなチェックコードは別についてる。昔から。
だからHDD以外方が怪しいんじゃ?
0514login:Penguin2013/11/20(水) 21:11:35.55ID:AVxrr1Rb
ZFSは2001年開発開始だがそれよりずっと前から誤り訂正は使われてる
>>512はドヤ顔でウソを語るクソ野郎
0515login:Penguin2013/11/20(水) 21:52:13.13ID:BDsQcIvp
WindowsでZFSが使える日が来たら僕は
0516login:Penguin2013/11/20(水) 22:00:27.05ID:elVQL5xQ
Zenzen tsukaenai File System for Windows
0517login:Penguin2013/11/20(水) 23:09:27.82ID:rmMhU9tO
>514
そうそう．昔から HDD 自体もエラー訂正はそれなりに
かけているわけだが，実際にたまに化けるわけだ

それこそ電源不良でとかそういう理由もあるんだろう

ZFSで scrub かけてるとほとんどは何もなかった，
だけどたまーに実際に「修復したよ」って言ってくるのは
なにかしら化けていたと言うことなんだと思う．
ZFS使ってなかったらそのエラーに気づくこともなかったんだろう
0518login:Penguin2013/11/20(水) 23:40:25.51ID:YOXke8Ow
その化けてるのは、ディスクで化けたのでなくて、メモリとかネットワークの上じゃないかな。特にメモリ。

各々のディスクは渡されたデータを正しく保持してるが、渡すところで腐ったので全体では不整合、という状態。
0519login:Penguin2013/11/20(水) 23:42:43.13ID:jbabelX+
>>512
今も昔もHDDは最初っから、セクタ単位でCRC使ってますが、なにか。
逆に今時の、記録密度が高いプラッタの方が、データが化ける可能性が高いんですが。
AFTだって、ただ容量効率だけを上げようってだけで作られた訳じゃないぞ？
記録密度が上がったおかげで、データが化ける可能性が高くなってしまった。
今までのCRCじゃ強度が足りず、エラーの発見率が落ちる。
それじゃ、エラーの発見率を担保するために、強力なCRC付けりゃ良いかというと、
512byte単位じゃ、CRCデータの方が大きくなって、結果、容量効率が落ちる。

だから、4kセクタにして、それに対して強度の高いCRCを付ける事で、
容量効率とエラーの発見率を担保してるんだが。
0520login:Penguin2013/11/20(水) 23:59:29.83ID:AVxrr1Rb
>>518
ディスクだってプロセッサやメモリを持ったコンピュータなんだぜｗ

>>519
リードソロモン符号とか昔から使ってるよね
■ このスレッドは過去ログ倉庫に格納されています