[NETGEAR] ReadyNAS総合 Part39 [X-RAID/RAIDiator]

■ このスレッドは過去ログ倉庫に格納されています
0001不明なデバイスさん
垢版 |
2018/04/05(木) 03:03:34.13ID:JRLqDss6
弾力的な運用が可能なNASキット、ReadyNASのスレ
上位製品にReadyDATAもありますが、話題になるのはReadyNAS製品で
ベアボーンモデル(=ディスクレス、相対的に廉価)がほとんどです

■NETGEAR製品情報
https://www.netgear.jp/products/business/nas
https://www.netgear.com/business/products/storage/
■ReadyNAS関連の公式サイト
NETGEAR日本語サポート(フォーラム・FAQ)
https://www.netgear.jp/supportInfo/
NETGEAR Community (英語)
https://community.netgear.com/t5/All-Communities/ct-p/English
ReadyNAS Downloads (英語)
https://kb.netgear.com/20684/ReadyNAS-Downloads
ReadyNAS Beta Release (英語)
https://community.netgear.com/t5/ReadyNAS-Beta-Release/bd-p/readynas-beta-releases

■前スレ
[NETGEAR] ReadyNAS総合 Part38 [X-RAID/RAIDiator]
http://mevius.2ch.net/test/read.cgi/hard/1516241424/
0339不明なデバイスさん
垢版 |
2018/05/02(水) 14:25:25.03ID:3+VRI2Go
>>335
バックアップ用には大容量単体ドライブを用意したほうがいいんじゃない？
0340不明なデバイスさん
垢版 |
2018/05/02(水) 14:44:19.30ID:BXEjEkxL
>>338
使うことできるがReadyNASからS.M.A.R.T.が取得できなかったりして不良セクタなどがあっても分からないよ
0341不明なデバイスさん
垢版 |
2018/05/02(水) 15:10:45.42ID:z1mN4+lE
>>339
>>340
8TBのHDDは頻繁な書き換えに不向きな物が多いのかと思っていたので・・・。
そうでもなさそうですかね。バックアップは単体のものを選択しようかと思います。

あとはビット腐敗への対処ができると良いのですが。
0342不明なデバイスさん
垢版 |
2018/05/02(水) 16:07:16.70ID:StL5XFTa
>>341
いっそのことバックアップ用にもう一台同じNAS買っちゃったら？
ちょっと金はかかるけど
0344不明なデバイスさん
垢版 |
2018/05/02(水) 16:22:42.65ID:jqz66A3S
>>337
SMRは止めた方がいいと思うよ〜
2.5inchの2TBを使ってるけど書き込み速度は半分になるし、熱くなるしで
自分は二度と買わない
0345不明なデバイスさん
垢版 |
2018/05/02(水) 16:30:36.57ID:BXEjEkxL
>>341
RAID0やJBODでBit RotはReadyNAS内部ボリューム含めてエラー検出できてもエラー訂正はできない
0347不明なデバイスさん
垢版 |
2018/05/02(水) 16:41:38.45ID:TyK5fChE
クラウドサービス使ったことないけど、何十TBって容量のバックアップ用途に使うのって現実的なの？
リストアの時ダウンロードの帯域細くて時間かかるって聞いたけど
0348不明なデバイスさん
垢版 |
2018/05/02(水) 16:57:45.35ID:z1mN4+lE
>>342
うーん。結構高くつきますね。
まずはバックアップ用に1台から始めた方が良いかな・・・。

>>343
ケチなもんで、最初から一点も豪華なとこが無かったかもですが・・・（汗
ま、二重化が安心ですよね。

>>345
あ、そうかもと思ってたのですが質問し忘れてました。
そうなのですね。ありがとうございます。
そもそもエラーが発生することは稀なのでその際には
バックアップから復元するというのが現実的な方針かなと思います。

>>346
数十TBは無いですが、今後10TB近くにはなる可能性もあるので
今のところは検討対象ではないですね。
0349不明なデバイスさん
垢版 |
2018/05/02(水) 18:19:48.48ID:zTwmkamw
正直消えたら人生終わるようなデータでも無い限りX-Raidとバックアップ用の外付けHDDの組み合わせでも十分だと思うけど…
絶対に消えたら困るってデータなら金に糸目を付けずにそういうサービスを使うべきだし
0350不明なデバイスさん
垢版 |
2018/05/02(水) 18:52:08.16ID:StL5XFTa
ビットロット保護ってbtrfsの機能を利用したものじゃなかったっけ？
ファイルシステムが違う外付HDDまで恩恵を受けられるかどうかかなり怪しい気がする
ビットロット保護に結構拘ってるみたいだからもう1台同じNASを買ったらどうかなって思った
（なので自分はバックアップ用にもう1台ReadyNASを用意してる）

外付HDDまでビットロット保護ができるかどうか自分で試してみればいいんだけど
外付のUSB HDDがないから試せない

>>347
リストアもそうだけどバックアップ時もな・・・
アップロード方向はプロバイダの転送量制限に引っかかりそうだ
0351不明なデバイスさん
垢版 |
2018/05/02(水) 19:15:26.91ID:Ihhrt5Qg
>>335
> NASの方はbitrot保護やディスクスクラブ機能があるのでビット腐敗への対策ができますが

ひょっとして、検索上位に表示される https://www.watch.impress.co.jp/netgear/try13/ の記事を真に受けている？

引用すると、
> Bit rotは、前述した4つの段階と違って、表に現れにくいエラーだ。ハードディスクの劣化などによって、
> 特定のbitが書き込まれた部分だけ読み取り不可能になるだけなので、該当する部分に書き込まれたデータを
> 読み取ろうとして、はじめてファイルが開けないなどのエラーが発覚する。
> 従来のReadyNASでも、「スクラブ」を手動で実行することで、1ビット以内のエラーを誤り訂正によって修
> 正することが可能だったが、ReadyNAS 6.2で追加された「Bit rot保護」は、自動的に実行する機能だ。
とあるけど、これ出鱈目だと思うぞ。

Arch Linuxでコピーオンライト使ってる俺からすると、上の解説はLinux初心者がいい加減な知識で書いた記事にしか思えない

ReadyNAS では「Bit Rot保護 (コピーオンライト)」と表記されており、
これは btrfs というファイルシステムの CoW (Copy-On-Write) のことを示していると思われる。
0352不明なデバイスさん
垢版 |
2018/05/02(水) 19:16:07.56ID:Ihhrt5Qg
これ、どういう機能なのかは
https://wiki.archlinux.jp/index.php/Btrfs#.E3.82.B3.E3.83.94.E3.83.BC.E3.82.AA.E3.83.B3.E3.83.A9.E3.82.A4.E3.83.88_.28CoW.29
が分かりやすい

> 今までに存在していなかったファイルを書き込もうとした場合、データは空き領域に書き込まれて、
> ファイルシステムのメタデータブロックが CoW されます。"通常の"ファイルシステムでは、ファイル
> の一部を上書きした場合、置換先のデータに直接上書きがなされます。CoW ファイルシステムでは、
> 新しいデータはディスクの空き容量に書き込まれて、それから、新しいデータを参照するようにファ
> イルのメタデータが変更されます。元のデータはどこからも参照されなくなって始めて削除されます。
> CoW にはアドバンテージがありますが、大きなファイルに小さなランダム書き込みを行うときのパフ
> ォーマンスについてはあまり良い影響を与えません。たとえ"コピー"を行わないときでもファイルを
> 断片化させるからです。データベースファイルや仮想マシンイメージについては CoW を無効化するこ

とあり、ようするにファイルの上書き中に電源断等のトラブルがあった場合に、元データが破損することがないというだけ。
0353不明なデバイスさん
垢版 |
2018/05/02(水) 19:16:26.97ID:Ihhrt5Qg
NetGearの公式の解説でも、
https://www.netgear.jp/solutions/readynas/readynas_btrfs.html
> Copy-on-Write（コピーオンライト）が実現する堅牢性
> EXT3やEXT4など多くのNASで採用されている従来型のファイルシステムは、ディスク上のデータを書き換える際、
> ディスク上のデータに上書きします。当たり前のように思えるこの動作は、実はとても危険なのです。
> データを書き換えている最中に電源障害やハードウェア故障、その他の不具合が発生すると、
> 中途半端な変更によってデータの不整合が発生したり、データが永久に失われてしまう恐れがあります
（略）
> BtrfsはCopy-on-Write（COW）という仕組みを導入することで、この問題を解決しています。
> BtrfsのCopy-on-Writeは、データを書き換える必要が発生すると、既存のデータを上書きするのではなく、
> ディスク上の新たな場所へ書き込みます。書き込みが問題無く完了したのを確認してから既存の（古い）
> データを削除することで、書き込み中の不具合によるデータの喪失を防ぐことができるのです。

と、単に Linux の Btrfs ファイルシステムにおける CoW であることが明記されている。
0354不明なデバイスさん
垢版 |
2018/05/02(水) 19:18:43.96ID:Ihhrt5Qg
ビット腐敗というのは、HDD で長時間アクセスしていないセクタが読み取りにくくなる現象のことを意味する。

今のHDDでビット腐敗が生じるのか、対策が必要なのかどうかは別として、
よく「使ってないセクタのHDDの磁気が弱くなる（※厳密には正しくないけど）」と呼ばれる物理的な現象のことで、
これを防ぐためには、HDDの使っていない領域を定期的に読み取ったりとか、ランダムデータを書き込めば良いと言われている。

で、ReadyNAS の BitRot保護＝Copy-on-Write（COW）は、この「ビット腐敗」とは関係がない。

インプレスの記者が、「ビットロット保護」を「ビット腐敗に対する保護」だと勝手に誤解して出鱈目な記事をまき散らしただけ。
0355不明なデバイスさん
垢版 |
2018/05/02(水) 19:28:15.32ID:Ihhrt5Qg
あと、>>335 の「ディスクスクラブ」については、副作用的な効果であるものの、使っている領域に対する「ビット腐敗」への限定的な対策にはなる。

何故ならば、データが書き込まれている領域については整合性の検査（読み取り）が行われるので、
長い間、読み書きされていないセクターに対する物理的な問題というのは解消される。
（ただし、完全なビット腐敗の対策として、書き込みも必要と考えるならば、完全なビット腐敗への対策にはならない）

しかし、ファイルが無いHDDで「ディスクスクラブ」をやると一瞬で終わるので、使っていない領域のビット腐敗への対策にはならない。
> 土 4月 7 2018 0:07:58 ボリューム: ボリューム hogehoge のスクラブが完了しました。
> 土 4月 7 2018 0:07:53 ボリューム: ボリューム hogehoge のスクラブが開始しました。

なお、今の HDD で、長時間読み書きしていない領域の読み書きに問題が生じるのか、ビット腐敗への対策が必要なのかは疑問
工学的に考えてディスクの外側を全く使ってなかったら、ヘッドの物理的な移動に問題が生じるとかの現象が起きないとは言い切れないけど、
一般的には、HDDのメーカーは、少なくとも保証期間内にはそのような問題は生じないように設計していると思う。

もし、ビット腐敗が生じるとしたら、ビット腐敗へのちゃんとした対策は ReadyNAS ではできないので、
もしビット腐敗がどうしても心配な人は定期的（半年に1回とか）、パソコンに繋いでツールで全領域をランダムデータに書き換えるなどをする必要がある。
0356不明なデバイスさん
垢版 |
2018/05/02(水) 19:50:33.96ID:4GQBOqBf
Bit Rot 保護
Bit Rot はディスクが段階的に変更され、徐々に信頼性が失われることを意味します。
ReadyNAS OS では RAID で保護されたディスクで Bit Rot を確認し、正しいデータに書き直
すことができます。
RAID 0 以外の RAID レベルはデータ冗長性を提供し、保護することができます。また、ディ
スクのリードエラーを正すことができる場合もあります。リードエラーは一度きりのエラー
の場合もありますが、ディスク上のデータが古くなって使えなくなってしまっている場合も
あります。Bit Rot 保護を有効にしていると、ディスクにエラーが検出された場合に、データ
が再書き込みされ、データの信頼性が復元されます。
Bit Rot 保護は ReadyNAS 上のすべてのフォルダーでデフォルトで利用可能です。


OS6のマニュアルに"Bit Rot 保護＝ビット腐敗対策"と書いてありますが
0357不明なデバイスさん
垢版 |
2018/05/02(水) 19:53:14.59ID:StL5XFTa
>>354
＞インプレスの記者が、「ビットロット保護」を「ビット腐敗に対する保護」だと勝手に誤解して
＞出鱈目な記事をまき散らしただけ。

ReadyNAS製品紹介ページで「ビットロットプロテクションはデータの腐敗を検知し復旧可能なうちに
破損データを修復する」と明言されてるけどこれも間違いだってこと？
0358不明なデバイスさん
垢版 |
2018/05/02(水) 20:04:55.74ID:j8S8vd0v
なるほどreadynasの説明って適当だったのか
買おうかと思ってたけどやめとこ
0360不明なデバイスさん
垢版 |
2018/05/02(水) 20:14:55.32ID:StL5XFTa
>>358
むしろID:Ihhrt5Qgの書き込みこそ推測だけで根拠がないんだが
少なくともメーカーは製品の仕様として「そういうことができます」とはっきり謳っているけど
ID:Ihhrt5Qgは管理画面上の表示（間違ってるかもしれんのに）を根拠に推測しているだけ

実際に自分で解析したとか、ネットギアのサポートフォーラムで質問をぶつけてみてメーカーから
公式に回答が返ってきたとかなら分かるけど、単なる推測で結論を出すのはせっかちすぎでは？
0361不明なデバイスさん
垢版 |
2018/05/02(水) 20:59:10.30ID:M/oqjdTx
Bit Rot 保護を有効にするとBit Rot 保護も機能するがCOWも一緒に有効になることを示している事だから間違いじゃないよ
0362不明なデバイスさん
垢版 |
2018/05/02(水) 21:33:01.01ID:5WkXUs0r
Netgearからなにか(先日のキャンペーンのだと思うけど)発送されたらしいのだが、
他にも居るかい?
0363不明なデバイスさん
垢版 |
2018/05/02(水) 22:41:55.92ID:z1mN4+lE
つまり、Bit ｒｏｔ保護≠ＣＯＷ ですかね。
ＣＯＷについては>>351の説明でおおむね合っていて
Ｂｉｔ rot保護はbitが時間の経過で反転しちゃう前に書き込みしなおして
健全性を保持する機能？
0364不明なデバイスさん
垢版 |
2018/05/02(水) 22:53:24.23ID:WXsSQrNs
つうかさ、データが化けたらデバイスレベルでCRCエラーになるんだから、単なる読取り不能セクタになるだけだろ。
それに備えてRAID組んでるんじゃないのか？
0365不明なデバイスさん
垢版 |
2018/05/02(水) 23:06:31.08ID:faqSr8jd
マニュアルに
> Bit Rot 保護はまたコピーオンライトとも呼ばれます。
とも書いてあるんだよな…
0366不明なデバイスさん
垢版 |
2018/05/02(水) 23:22:50.22ID:U8sXHyTh
Win10アップデートしたら、FW4.2.31のReadyNASのファイル共有出来なくなった
余計なことばかりしやがって・・・

ttps://support.microsoft.com/ja-jp/help/4034314/smbv1-is-not-installed-by-default-in-windows
0368351-355
垢版 |
2018/05/03(木) 00:42:41.09ID:IJ8SFn7J
>>360-361
ご指摘ありがとうございます。

>>365 さんも言っているように、マニュアルに「Bit Rot 保護はまたコピーオンライトとも呼ばれます。」とあったので、
Bit Rot 保護 = コピーオンライト だと判断して、>>351-355 を書きましたが、
公式のサポート記事にこの機能についての詳しい解説があり、誤りであることが判明しました。

Bit-rot Protection and Copy-on-Write (COW) in depth
https://kb.netgear.com/26091/Bit-rot-Protection-and-Copy-on-Write-COW-in-depth


> When Bit-rot Protection is enabled, COW is enabled. When Bit-rot Protection is disabled, COW is disabled as well.

正しくは、「Bit Rot保護 (コピーオンライト)」を有効にすると、
「Bit-rot Protection」と「Copy-on-Write (COW) 」の両方が有効になり、
無効にした場合には、「Bit-rot Protection」と「Copy-on-Write (COW) 」の両方が無効になるとのことです。

（※日本語マニュアルの「Bit Rot 保護はまたコピーオンライトとも呼ばれます。」という説明は間違いなようです）
0369不明なデバイスさん
垢版 |
2018/05/03(木) 00:43:15.12ID:IJ8SFn7J
ReadyNAS における Bit-rot Protection の解説も同じページにあり、これはHDDのビット腐敗防止の為の機能で、
このチェックボックスを有効にすると、チェックボックス [有効後] に書き込んだデータについて、
チェックサムが作成されるので、ビット腐敗が発生した際に検出が可能とのことです。
あと、データの上書きの際に、古いデータを残したままで、他の場所に新しいデータを書き込むので、前のデータがそのままスナップショットにできるとのこと。
チェックボックスを無効にすると、無効にした後に書き込んだデータについては、チェックサムが作成されないので、
新しく書き込んだデータについてのビット腐敗を検出ができないとのことです。

「It fixes corrupt bits as long as you have more then one drive in the raid.
　It fixes them when it detects them on reads, or when you do a filesystem scrub.」
壊れたビットを修正できるのは、RAID 1 以上の場合のみとあるので、 Bit-rot Protection でできるチェックサムは検出のみで、
「Bit Rot保護 (コピーオンライト)」が有効ならば、エラー（ビット腐敗等）を検出した後、RAID の別HDDを使用してデータを修復できるとのこと。

また、btrfsはCOWとB-treeをインテリジェントに実装しているので、COWを無効または有効にしても
ボリュームスペースで許される数だけスナップショットを作成でき、Bit Rot保護のON/OFFでスナップショットに影響がないとのこと。

注意点として、
・すでに書き込まれた/データを持つファイルは、COW / Bit-rot Protectionの状態を変更できない（新たに書き込むデータのみに影響）
　ただし、サイズが空のデータは例外として、切り替わる。
・「Bit Rot保護 (コピーオンライト)」を有効にすると断片化が激しくなるので、仮想化や小さな書き込みパターンのファイルには向かない。
　100万個の画像ファイルがあるようなケースでは、無効にすべき。
と書かれてました。
0371不明なデバイスさん
垢版 |
2018/05/03(木) 00:55:06.59ID:IJ8SFn7J
>>370

無駄に長くなったので5行で書くと、

・ 「Bit-rot Protection」は、チェックサムを記録し、読み取り時に必ず検証する機能（データ修復は RAID で自動的にやる / RAID無しなら検出のみで修復不可）
・「Copy-on-Write (COW) 」は、データ書き換え時に、元データを直接上書きせずに、ディスク上の新しい場所に書き込むこと。
・ReadyNAS OS 6.2.0+ では「Bit Rot保護 (コピーオンライト)」を有効にすると、
　新しく書き込んだファイルについて、「Bit-rot Protection」と「Copy-on-Write (COW) 」の両方が有効になる
　どちらか一方のみを有効or無効にすることはで
0372不明なデバイスさん
垢版 |
2018/05/03(木) 00:56:49.90ID:IJ8SFn7J
(続き)
きない。


--

あと、
「例えば RAID 5 アレイはパリティを持っていて、欠けているデータを再構築できるのだから、
　そもそも Bit-rot Protection は意味がないのでは？」という疑問については、
NetGear公式サポートページからリンクされていた英語の記事が参考になりました。
https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/　の
記事が参考になりました（ReadyNAS の解説ではなく、ZFSとbtrfsの解説なので注意）。

RAID のパリティは読み取り事に検査されることはないので、
極めて小さい破損やビット腐敗で特定のビットのみが入れ替わったようなケースがあっても、
データ破損があったことを判定できずそのままファイルの転送が正常に終わったかのような状態になってしまう
（破損していることに気が付けない）とのこと。

Bit-rot Protection が有効ならば、読み取り時にチェックサムを必ず検証するので、異常があったことに気が付けるという意味がある模様。
0373不明なデバイスさん
垢版 |
2018/05/03(木) 01:03:42.98ID:fN4zdzuw
>>368
> （※日本語マニュアルの「Bit Rot 保護はまたコピーオンライトとも呼ばれます。」という説明は間違いなようです）

どうでもいいことだけど、これ元の英文マニュアルも "Bit rot protection is also called copy-on-write."
とか書いちゃってるんだよね
同じマニュアルの別の箇所にはちゃんと "Enabling bit rot protection also enables copy-on-write."
って書いてあるのに
0375不明なデバイスさん
垢版 |
2018/05/03(木) 02:07:06.07ID:TRBrR7jR
>インプレスの記者が、「ビットロット保護」を「ビット腐敗に対する保護」だと勝手に誤解して出鱈目な記事をまき散らしただけ。

ググればインプレスだけではなくアスキーもReadyNASのBit Rot 保護についての記事を出していることが簡単に分かるし
取説等を見ればこんな結論にならないはずだが
一言で言えば

ID:IJ8SFn7J　ID:IJ8SFn7Jが、「ビットロット保護」を「COW」だと勝手に誤解して出鱈目なレスをまき散らしただけ。
0376不明なデバイスさん
垢版 |
2018/05/03(木) 02:30:01.54ID:PMJhvebZ?2BP(1000)

>>374
自動デフラグとかディスクスクラブは終わらないトラブルがあるイメージ

ビットロットはよくわからん
ビット腐敗が起きたらCRCエラーの後再読み込み、SMARTで代替処理されるか、回復不可能セクタになるんじゃないのか？

あとはcowは突然の電源断がないように、UPSさえきちんとしてれば問題なさそうだし

よって、無駄な事はしない

ウイルスチェックも有効にしない
firmwareもインストールした時のものからアップデートはしない

まあそれもまた人それぞれ
0377不明なデバイスさん
垢版 |
2018/05/03(木) 03:50:21.77ID:x/wR2b7n
>>374
ビットロット保護はON、自動デフラグはOFFにしてる

>>376
ディスク障害とビットロットはまた別物じゃないの？
0378不明なデバイスさん
垢版 |
2018/05/03(木) 09:21:00.36ID:Eotp+DS/
>>377
デバイスレベルのエラーチェックをすり抜けて、化けてるデータがさもエラーが無いように正常に読み取れるケースってどんな確率なのよ
データとエラーチェックコードに矛盾が無いよう多ビットが都合よく化けないとそんなこと起こらないぞ？
bitrot保護に何を期待してるのかさっぱりわからん。

>>372
RAIDはRAID、ファイルシステムはファイルシステムでレイヤーが別なんじゃないの？
ファイルシステム的にチェックサムを持たせても、それが不一致な場合にどのディスクにエラーがあるのかはRAID5では分からず、それを分かるようにするにはRAIDを構成するディスク毎にチェックコードが必要になるよね。
ましてパリティディスク上に任意のチェックコードを書くなんてファイルシステムの範疇じゃ無理でしょ。
だからbitrot保護ってのはちゃんと書けたか検査をしてるだけじゃないの。
昔で言えば verify on の状態で、それをCoWと組み合わせて最悪でもロールバックできるようにしてるのでは？
0379不明なデバイスさん
垢版 |
2018/05/03(木) 09:41:35.21ID:OphVE0Nt
>>335 の相談からズレてきてる気がする。
将来的に容量を増やす可能性があるならraid0は避けた方がいいんじゃ？
RN214に8TBx2のX-RAID(RAID1)でスタート。
取り敢えずbackupはsnapshotで誤魔化して、どうしてもちゃんとしたbackupが必要なら上記のをもう1セット

後々もっと容量が必要になったら8TB HDDを追加してRAID5に再構成(X-RAIDなら自動)すれば16TBになる
0380378
垢版 |
2018/05/03(木) 09:45:10.63ID:Eotp+DS/
>>378
結論が足りてなかった。
ようするにbitrot保護はRAIDとは関係無い仕組では？
実際ファイルシステムがシンプルなRAID構成の上に乗るとも限らず、linuxなんて仮想化や抽象化を何層も重ねられるわけで、readynasですら複数の構成のRAIDをLVMで束ねた上にbtrfsがあるんだから、
ファイルシステム視点であるデータがRAID上のどのディスクのどの位置にあるかを把握するのは容易じゃないよ。
RAIDを内包したZFSなんかは一味違うだろうけど。
0381不明なデバイスさん
垢版 |
2018/05/03(木) 12:18:23.09ID:Xu2LP0ow
スクラブしときゃあいいんだよ(AA

どっかで読んだけどビットロットは読み込んだ時に検証される機能やから、読まないファイルは検証されず、ぶっ壊れる可能性が高くなるとあった記憶が。(´・ω・｀)

なんで、スクラブしときゃあ、とゆー結論のもと、ビットロット無効でツキイチスクラブしてます。
0383不明なデバイスさん
垢版 |
2018/05/03(木) 13:29:45.75ID:QrSb6BPa
>>379
「将来的に増やすかも」＝「5年、10年先のことは分からない」という程度の意味なので
とりあえずは大丈夫です。

>>378 >>379
bitrot保護ってしばらくアクセスしてないデータに対して
勝手に検査（可能なら修復）してくれる機能ではないんですか？
ベリファイとは違う気が・・・。
0384383
垢版 |
2018/05/03(木) 13:34:07.61ID:QrSb6BPa
>>381
あばばばば。
そうなのですね。bitrot保護って更新日時とかから自動でやってくれるのかと・・・。
ま、 スクラブしときゃあいいんだよ ですね。
0385不明なデバイスさん
垢版 |
2018/05/03(木) 13:38:41.47ID:x/wR2b7n
>>383
ID:IJ8SFn7Jのレスを読んだ限りでは「データを書き込む時にチェックサムを記録しておくので、
次回読み出した時にビット腐敗が発生していた場合は自動的に修復してくれる」って感じかな？
アクセスしてない間にデータが化けまくってチェックサムで修復できる範囲を超えたりしない限り
この実装でも問題ないのかもしれない
0386不明なデバイスさん
垢版 |
2018/05/03(木) 13:56:21.24ID:Eotp+DS/
>>385
書いてすぐ検証しなければCoWしても何も担保できなくない？
なんにしてもメカニズムのよくわからない機能に頼るより別の対策を立てる方が真っ当だわな。
0387不明なデバイスさん
垢版 |
2018/05/03(木) 14:08:59.08ID:Xu2LP0ow
>>384
bitrot impress でググったら紹介されてるページがトップにきますな。筆者が認識を誤ってる可能性もありますが。

修復可能なら出来るようパリティ作るみたいやし、無駄ではないやろけど、片手落ちすなぁ(;´д｀)
0389不明なデバイスさん
垢版 |
2018/05/03(木) 14:50:42.92ID:Eotp+DS/
あれ、そもそもCoWって元データを直接書き換えず空き領域に書くようなやり方のことだっけ？
データをコピーした時点では複製を作らず、同じ内容であるはずのいずれかのデータに書き込みをした時点で実際にコピーを作る手順のことだよな？
これってスナップショットに使う技術じゃないのかね？
0390不明なデバイスさん
垢版 |
2018/05/03(木) 15:15:21.72ID:A4K+UAdj
スナップショット「にも」使う
データ更新をアトミックにするためにも使う
0391不明なデバイスさん
垢版 |
2018/05/03(木) 15:24:40.91ID:Eotp+DS/
>>390
アトミックに更新すべきデータって、データ本体とチェックサムかな？
じゃあbitrot保護の根幹はチェックサムであってCoWはその手段ってことだから、CoWしてるかどうかは本質とは関係無い話ってことか。
やっぱbitrot保護に何かを期待するような点は無さそうだな。
0392不明なデバイスさん
垢版 |
2018/05/03(木) 16:05:08.27ID:Dcm5HmBN
Bit Rotとスクラブの違い

まずチェックサムはBit RotがONになっていなくてもボリュームの設定でチェックサムがONになっていたらデータのチェックサムはメタファイルに記録される


スクラブは全データのメタファイル+生データ+パリティの3つのチェックサムを確認する

スクラブは生データおよびパリティのチェックサムをその都度計算してメタファイルに記録されたチェックサムと同じかどうかを全データチェックする
違いがあった場合はメタファイルのチェックサムと同じデータを正として訂正する


Bit Rotはファイルアクセス時のみ生データ+パリティのに記録された2つのチェックサムを確認する

Bit Rotはファイル書き込み時にファイルデータにチェックサムを書き込んでおきファイルアクセスしたときだけ生データおよびパリティのチェックサムが同じかどうかをチェックする
違いがあった場合はスクラブと同じ手順で確認訂正する


Bit Rotはファイルアクセスの度にチェックサムを求めていたら負荷がさらに増えるから生データとパリティに予めチェックサムを書き込んでそれだけを確認してるだけ
ID:IJ8SFn7Jはそのことを理解していない
0393不明なデバイスさん
垢版 |
2018/05/03(木) 16:59:28.04ID:e1FFn0Gz
>>392
> （スクラブは）違いがあった場合はメタファイルのチェックサムと同じデータを正として訂正する
> （Bit Rotは）違いがあった場合はスクラブと同じ手順で確認訂正する
それは間違い

btrfs の仕様では、チェックサムではエラーを検出のみで訂正にはRAIDが必要
チェックサムで出来るのはエラー検出のみ、訂正はRAIDの方の機能（JBODなら訂正不可）
https://lime-technology.com/forums/topic/60493-can-btrfs-fix-bitrot/

"What is scrubbing?" には、スクラブのエラー訂正には RAID Array Level 1 以上が必要とある
https://kb.netgear.com/app/answers/detail/a_id/26941/
> If multiple hard discs are used in a RAID Array Level 1 or greater then scrubbing will also correct any errors found automatically.

bit rot protection は RAID 1以上のドライブに限り壊れたビットを訂正するとある
https://kb.netgear.com/26091/Bit-rot-Protection-and-Copy-on-Write-COW-in-depth
> What is bit rot protection in detail? It fixes corrupt bits as long as you have more then one drive in the raid.

ついでに、"If bitrot protection is turned off, regular scrubbing is not required."
ビットロット保護機能がオフの場合、定期的なスクラブは不要とある。


> Bit Rotはファイルアクセスの度にチェックサムを求めていたら負荷がさらに増えるから
> 生データとパリティに予めチェックサムを書き込んでそれだけを確認してるだけ
この部分、完全に意味不明なんだが……
チェックサムというのは、書き込み時に計算したチェックサム（メタデータなどに記録）と、
読み込み時に計算したチェックサム（読み込んだ生データから計算）の一致を確認することで、ファイルの破損を検出する技術
負荷がかかるのは「チェックサムの計算」だから、「ファイルアクセスの度にチェックサムを求めていたら負荷がさらに増える」のはその通りだけど、
チェックサムの計算は、初回書き込み時と、読み込み時に必ずやる必要がある
読み込み時に読み込み生データから毎回計算しない限り、破損検出は不可能（計算結果をキャッシュしたら、キャッシュ後の破損を検出できない）
0394不明なデバイスさん
垢版 |
2018/05/03(木) 17:08:03.47ID:7GWTFP7h
いつまで続くのこのやり取り
ネットギアに問い合わせて終わらせてくれよ
0395不明なデバイスさん
垢版 |
2018/05/03(木) 17:14:09.61ID:9W/d3gH1
伸びてるから526Xの安売りでも来てるかと思ったら不毛な議論かよ
0397不明なデバイスさん
垢版 |
2018/05/03(木) 17:51:22.71ID:nVEkHUh+
ちな、なんでかな
>ついでに、"If bitrot protection is turned off, regular scrubbing is not required."
>ビットロット保護機能がオフの場合、定期的なスクラブは不要とある。
0398不明なデバイスさん
垢版 |
2018/05/03(木) 17:57:04.59ID:+1Yivwvh
>>393
ちゃんと >>392 にパリティって書かれているじゃん
パリティってRAID5や6のパリティデータの事だぞ
0399不明なデバイスさん
垢版 |
2018/05/03(木) 17:58:33.95ID:GGQ6TkcR
OS6のスクラブは全セクタ舐めてRAIDのパリティチェックするんじゃなくて
btrfsのチェックサム確認なんでしょたぶん
0400393
垢版 |
2018/05/03(木) 18:39:23.56ID:e1FFn0Gz
>>398
あ、>>392 の「パリティ」は、RAID5のパリティのことだったのか

それなら、スクラブは、「HDDに記録されたデータ」と「HDDに記録されたデータをRAID5のパリティで訂正したデータ」のうち、
メタファイルのチェックサムと一致したデータを正しいものとして、
「HDDに記録されたデータ」もしくは「RAID5のパリティ」のどちらか（チェックサムと一致しなかった方）を修正するってことで、
非常に納得できる

けど、そうなると
> Bit Rotはファイルアクセスの度にチェックサムを求めていたら負荷がさらに増えるから
> 生データとパリティに予めチェックサムを書き込んでそれだけを確認してるだけ
が更に意味不明になるな

「RAID5のパリティ」に「チェックサム」を書き込む？
0402不明なデバイスさん
垢版 |
2018/05/04(金) 12:42:31.24ID:VVaYqLa7
316で最新OSにしたらTimemachineはSMBになったんだけど、macからYimemacineを実行すると凄く遅い。
TrueImageで同じNASにバックアップすると半日で終わるのにTimemachineだと一日かかっても終わりません。

SMBの暗号化はオフにしてありますが他に設定することありますか？
0403不明なデバイスさん
垢版 |
2018/05/05(土) 21:24:12.75ID:umCSyAHi
質問です。

ReadyNAS 104 (RN10400) ファーム 6.9.3 を使っているのですが、
デフラグを実行すると、約1.4TB だったデータが 約1.8TB に増大（約370GB増大・約25%増大）してしまいます。
データの中身は、数十MBの動画ファイル2万個ぐらいで、特に特殊な使い方をしているわけではありません。

増大したデータをNAS のバックアップ機能で他の場所にコピーすると、もとの容量に戻りますが、それをデフラグするとまた同様に増大します（再現性があります）。
ただし、2回以上連続でデフラグした場合は、繰り返し増大するわけではないので、デフラグで増大は1回限りです。

https://kb.netgear.com/app/answers/detail/a_id/26941/ には、
スナップショットを使っている場合はデフラグでデータ量が増大することがあるとありますが、
Bit Rot保護（コピーオンライト）は使っているものの、スナップショットは一切使っていません。

デフラグ後にバランスをしても、増大したままでした。
スクラブで戻るかどうかは、古い ReadyNAS なせいかスクラブに20日間ぐらいかかるので、まだ試していません。

皆さんもスナップショット不使用で、デフラグでデータ量が増大（HDDの空きが少なくなる）する現象は発生しますか？
また、何か対策はあるのでしょうか？

教えてください。
0404不明なデバイスさん
垢版 |
2018/05/05(土) 21:25:38.05ID:umCSyAHi
デフラグ前後で、NASの管理ページの共有タブの当該共有名の「使用量」が増大します。
"btrfs filesystem df" コマンドで確認したところ、Metadata ではなく Data が大幅に増大しています。
しかし、ボリューム全体のファイル容量の合計 (du -b) や、Windows Explorer (SMB) での全ファイルの容量は、デフラグ前後で同一でした。
実際のファイル容量は変わっていないのに、何故かファイルシステム上の Data の容量が増えているのです。

【デフラグ前】約 1.4 TB
root@NAS:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md127 2.8T 1.5T 1.3T 53% /DiskHoge
root@NAS:~# btrfs filesystem df /DiskHoge
Data, single: total=1.42TiB, used=1.42TiB
System, DUP: total=32.00MiB, used=192.00KiB
Metadata, DUP: total=2.50GiB, used=1.50GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

【デフラグ後】約 1.8 TB
root@NAS:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md127 2.8T 1.8T 966G 66% /DiskHoge
root@NAS:~# btrfs filesystem df /DiskHoge
aData, single: total=1.78TiB, used=1.78TiB
System, DUP: total=32.00MiB, used=224.00KiB
Metadata, DUP: total=2.50GiB, used=1.87GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

【デフラグ前後で変わらないデータ】
[Windows Explorer (SMB) で調べたファイル情報] … デフラグ前後でバイト単位で完全一致
ファイル数 : 22,152
フォルダー数 : 1,198
サイズ : 1.41 TB (1,561,951,607,344 バイト)
ディスク上のサイズ : 1.41 TB (1,561,997,369,344 バイト)
NAS に SSH でログインして調べたファイル容量の合計 (du -b) も同様に変わらず
0407不明なデバイスさん
垢版 |
2018/05/05(土) 23:34:17.65ID:wtctnlMQ
>>406
403,404 って繋がってたのか。後半しか読んでなかった。

スナップショット無いのに、デフラグすると使用量が増えるケースは、経験だと近いうちにファイルシステムがリードオンリーマウントしかできなくなって、そのうちマウントすらできなくなる。

古い、使われてないトランザクションがガベージコレクトされていくべきなんだけど、ガベージコレクトの対象にならないケースになってるんだと思う。
読めるうちに別のハードディスクにデータ退避させてファイルシステム作り直した方がいい。
0408不明なデバイスさん
垢版 |
2018/05/05(土) 23:38:56.00ID:hips4INU
>>404
デフラグで使用容量が増えるのはbtrfsの仕様
運が悪ければボリュームフルになる欠陥品

https://docs.oracle.com/cd/E39368_01/E41138/html/ol_use_case1_btrfs.html
>コピーオンライトのコピーが含まれるファイルまたはサブボリュームをデフラグすると、ファイルとそのコピー間のリンクが破損します。
たとえば、スナップショットが含まれるサブボリュームをデフラグすると、スナップショットがサブボリュームのコピーオンライト・イメージではなくなるため、サブボリュームとそのスナップショットによるディスク使用率が増加します。

https://kb.netgear.com/26941/ReadyNAS-OS-6-An-overview-of-relevant-scheduled-maintenance-tasks-available
>Fragmentation produces a considerable amount of data overhead, so defragmenting a volume can lead to an increase in free space available

http://mevius.5ch.net/test/read.cgi/hard/1515665033/113
0409不明なデバイスさん
垢版 |
2018/05/05(土) 23:41:50.91ID:5jjPlKvN
やっぱbtrfsはまだ不安定なのかね。
なんとなくまだ様子見気分でいる。
OS4 の拡張の壁を取ってくれるだけでいいんだけどな。
0410不明なデバイスさん
垢版 |
2018/05/05(土) 23:49:01.11ID:rzmRxJJF
pro6でデグレして新品ディスク交換したんだけど待機中セクタが増え続ける。また不良ディスクなのか…
0411403
垢版 |
2018/05/06(日) 00:03:17.04ID:tozVlUUJ
>>407
ありがとうございます。
自分のケースでは、スナップショットは一切使ってませんが、
3つ (RAID1, JBOD, JBOD) のボリュームでデフラグで使用量が増える現象が発生するので、特定のボリューム固有の現象ではないようです。
もっとも同じNASなので、3つとも同じようにファイルシステムがおかしくなってるか、そもそもNASのOSレベルで何か変になってるかもしれませんが……。
> リードオンリーマウントしかできなくなって、そのうちマウントすらできなくなる
これは恐ろしい症状なので、デフラグはやめて、バックアップを複数とっておくことにします。

>>408
リンク先のフォーラムや記事はスナップショット有効の状態の場合についてのようですが、
自分のケースでも COW は有効にしているので、そっちが悪さしてるのかも……(´･ω･`)
0412不明なデバイスさん
垢版 |
2018/05/06(日) 00:18:51.57ID:1Gn1hWaW
>>411
>コピーオンライトのコピーが含まれるファイルまたはサブボリュームをデフラグすると、ファイルとそのコピー間のリンクが破損します。
とあるからCOWが有効だとなるんじゃね
0413不明なデバイスさん
垢版 |
2018/05/06(日) 00:34:50.61ID:Ts7nLlno
>>411
COWを有効にしているとなるよ
デフラグで断片化したファイルを整列させるのではなくて
断片化したファイルのコピーを整列させて断片化したファイルはそのまま存在するから
Btrfs上からは多重に容量カウントされて容量が増加する
0414403
垢版 |
2018/05/06(日) 00:57:05.44ID:tozVlUUJ
>>412-413
ありがとうございます。
COW有効だとスナップショット無しでも駄目なんですねorz

デフラグ作業でコピーが作られて、デフラグ前のファイルも容量にカウントされる（ファイルシステムのメタデータからのリンクが消失しない）現象が起きるとなると
容量が増大してしまいますね……。

なんか Btrfs のデフラグ機能自体が欠陥品なような気がしてきました。
もうデフラグはしないことにして、断片化でパフォーマンスが低下したら他のボリュームへのファイルコピーで断片化を解消しようと思います。
0416不明なデバイスさん
垢版 |
2018/05/06(日) 13:08:10.16ID:T76GQGgd
問題はメタデータにいろんな情報詰め込みすぎて複雑化した所為だろうな
スナップショットとコピーオンライトを使わなければデータ10TBくらいでメタデータサイズは数十MB程度
スナップショットかコピーオンライトを有効にするとメタデータサイズは数十GB〜数百GBまで膨れあがる

>>404をみると
データ1.42TiBでメタデータ1.50GiB
データ1.78TiBでメタデータ1.87GiBと370MiB増えている
0417不明なデバイスさん
垢版 |
2018/05/06(日) 15:08:57.46ID:1HqtTbli
readynas102使用中、近所に雷落ちた瞬間電源が落ち、
再起動したら外付けUSBドライブが読み込みできるものの書き込みできない状態になりました。
usbクレードル変えても同じで管理画面に前回安全な取り外しが行われなかった為に書き込みできない旨のメッセージ出てます。
これをフォーマット等せずに再び書き込み可にする方法ありますか？
0420不明なデバイスさん
垢版 |
2018/05/06(日) 17:03:37.58ID:nAXwkb6Q
OSからフォーマットかけただけでは直らない場合
そのUSBフラッシュ専用のフォーマットリセットツールがあったりする
0421不明なデバイスさん
垢版 |
2018/05/06(日) 17:56:03.71ID:9nZODWvb
>>417
それ簡単に直る
Windows PCがあったらそっちにつないでディスク修復すればいい
ReadyNAS本体だけだと直らないから一度別PCにつないで直す必要がある
NetGear公式にもそう直せと

イレギュラーで外されたHDDのフラグが立ったままだとReadyNASが
拒否るので、PCでフラグを消すだけなんだけどね
0423不明なデバイスさん
垢版 |
2018/05/08(火) 04:19:06.22ID:nTM0INos
NTFS形式なら、Windows PCにつないで
ドライブのプロパティ＞ツール＞ディスクのエラーをチェック　を実行

FrontViewから手順を踏まずに取り外すといつも起こるから
ReadyNAS単体でもディスク修復できるようにしてくれると嬉しいんだけどなぁ
0424不明なデバイスさん
垢版 |
2018/05/08(火) 19:07:16.67ID:VdAR4/SL
NTT-Xに来てんぞ

RN528X00-100AJS @89,980円 44台

RN526X00-100AJS @69,980円 28台

RN524X00-100AJS @49,980円 100台以上
0426不明なデバイスさん
垢版 |
2018/05/08(火) 19:53:12.59ID:E2jEA/eh
それいったらX-RAIDのエックスってなんだよっていうね
XやZがカッコいいと考えてる中二病経営者がいるんだよ
0432不明なデバイスさん
垢版 |
2018/05/09(水) 01:00:27.84ID:Exrl1BKy
良い時期は来年2月になるけどなｗ
半期決算前の9月にワンチャンあるかもしれんけど安くなった記憶ないな
0433不明なデバイスさん
垢版 |
2018/05/09(水) 16:45:20.16ID:VVnYnXg6
http://bbs.kakaku.com/bbs/K0000855480/SortID=21775511/
> ボリューム使用量は 60% で問題ないのですが、
> Metadata領域に空きがございませんでした。
>
> ファイル数が多すぎるため現象が発生していると考えられます。
> 現在の8割程度にファイル数を減らした後に再度ログファイルを取得頂き、
> 「btrfs.log」内の「Metadata」の使用量が8割程度に減少するかを
> ご確認ください。
> 「btrfs.log」内の「Metadata」の使用量が8割程度に減少した場合、
> そのまま運用再開していただき、現象が再発しない事をご確認をお願いいたします。
> ※ReadyNASへのファイル追加は控えてください。

この話のようにファイル数多すぎると見かけ上は空き容量があっても、
実は裏でメタデータ増えすぎてていきなりディスクフルになった挙句に
アクセス不能になるとかありえる話？

これネットギアの問題？、それともBTRFSの問題？
怖くて使えんのだが
0434不明なデバイスさん
垢版 |
2018/05/09(水) 18:06:02.53ID:3ob+uvF2
その人がどういう設定にしてるかとか総ファイル数がどのくらいとか分からんが60%しか使えないなら考え物だな
常用するならさらに空きがないと書き込みできないだろうし酷過ぎる

Metadata領域を除外して使用量60%ってなら残りはMetadata領域などが40%も使ってることになるし
そうじゃないなら容量は余ってるけど「ファイル数」が限界ってことだろうし・・・・面倒だ

もし後者ならrarとかに圧縮して1つにまとめたらMetadata領域に空きができるんだろうか
0437不明なデバイスさん
垢版 |
2018/05/09(水) 19:45:41.85ID:WMen0Xdf
>>436
原因の一端がCOWとスナップショットだから
それらを使わなければトラブルも少ないよ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況