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

**不明なデバイスさん** · 2018/04/05(木) 03:03:34.13

弾力的な運用が可能な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/

**不明なデバイスさん** · 2018/05/09(水) 21:35:53.66

Btrfsはゴミ
やたらとZFSを意識しているが、大言壮語も甚だしいほどに機能不足＆超絶不安定。

まず良く言われているようにスナップショットが容量食い過ぎ。
わざわざ「btrfs filesystem df /」なんてやって確認してくれるソフトなんて無いので、
dfの値だけみてスナップショットは容量食わないとか勘違いして、じゃんじゃんスナップ切ってくと
ある日突然disk fullで死ぬ。スナップショットなんだか、単なるコピーなんだか分かりゃしない。
ext*系によくある、スーパーユーザーのみが利用できる予約ブロックなんてものも存在しないので、
disk fullで死亡後は、リカバリがちょっと面倒くさい。

更にXFS以上にファイルの新規作成が遅い。
両者共に動的i-nodeにこだわりすぎてて、ギリギリまで作ってないからファイルの新規作成が遅いが、
XFSに比べBtrfsの新規作成は我慢ならないレベルで遅すぎる。
暇があったら、btrfs filesystem balance で強制的にリバランスしてるくらいでないと話にならない。
またSSDならともかく、HDDならリバランス後にデフラグ必須。

そして最も我慢ならないのが不安定さ。
昔、こじまみつひろさんなんかもいきなり読めなくなって嘆いていたが、
unstableが取れた今でさえ、そういうことが稀によくある。
そもそもディスクレイアウトが公開されておらず、「ソース読んで直接理解してね」という状況なので、
読めなくなる＝復旧不可能というお寒い状態。
Btrfs RAIDかけていようがどうしようが、いきなり読めなくなるので冗長性など無意味。
しかもカーネルが刺さるだとか、IOエラー吐くなんてのは、稀にどころか日常茶飯事。
Btrfsの使用は、もはやtaints kernel。

**不明なデバイスさん** · 2018/05/09(水) 21:36:27.73

ついでに言っとくと、btrfs-toolsとカーネルバージョンの相性問題も中々に酷い。
両者ともに最新版を使っているなら問題ないが、どこぞのディストリみたいに枯れたカーネル使ってて
しかしbtrfs-toolsだけが自分でビルドして使ってるとかだとちょっとした悲劇に見舞われる時がある。
btrfs-toolsはディストリのビルド品を使ってるいるが、カーネルはgitから最新開発版を使ってるとかだと
ある日突然読めなくなったりする。

暇だったら、どうでもいいプロジェクトのリポジトリの保存先にBtrfsを使ってみると嫌でも良くわかる。
少なくとも現時点では、ZFSと比較できるようなシロモノではない。
むしろあのザマで良くカーネルに取り込まれたなってレベル。
BtrfsはもうRHELじゃなくてもdeprecated扱いでなんら問題ない。

（https://linux.srad.jp/story/17/08/07/0951226/ より引用）

**不明なデバイスさん** · 2018/05/09(水) 21:41:16.34

ファイル数多いとメタデータ肥大化で不具合起こりやすいので、できる限り減らすのが良い
例えば、画像ファイルが大量にある場合には zip でまとめて、zipのまま閲覧できるビューアーアプリを入れるなどの対策がおすすめ

**不明なデバイスさん** · 2018/05/09(水) 22:58:31.67

>>437
ゴミ箱も復活させてほしいがな

**不明なデバイスさん** · 2018/05/09(水) 23:05:53.90

使い方気にしなきゃいけない時点でもう間違ってると思う
男は黙ってext4

**不明なデバイスさん** · 2018/05/09(水) 23:56:47.69

btrfsで問題ないけど、スナップショット便利です

**不明なデバイスさん** · 2018/05/10(木) 00:35:38.59

6Tで14000円以下か・・・Blueだけど
https://nttxstore.jp/_II_WE15185263?LID=mm&;FMID=mm

**不明なデバイスさん** · 2018/05/10(木) 00:58:27.66

9円のクーポンて初めて見た

**不明なデバイスさん** · 2018/05/10(木) 04:39:12.07

>>434
データ領域とMetadata領域は別

Metadata領域は最初に1GB割り当てられてMetadataの増加とともに自動拡張される
ただし自動拡張よりMetadataの増加が早かったりデータ領域を80～90%以上使用してしまうと
Metadata領域はそれ以上拡張できずにMetadata領域が足りなくなる
Metadataを書き込むことができないのでデータ領域が空いていても書き込み不可となる

>>404
Metadata, DUP: total=2.50GiB, used=1.50GiB
Metadata, DUP: total=2.50GiB, used=1.87GiB

total=2.50GiBが現在の割り当てられたMetadata領域
used=が現在のMetadata量
DUP　Metadataは標準で2重に作られるので実際のMetadata領域とMetadata量は倍になる

**不明なデバイスさん** · 2018/05/10(木) 07:29:30.81

気になったんで家の628X（bitrot保護ON、スナップショットOFF）も確認してみた

root@NAS01:~# btrfs filesystem df /Volume/
Data, single: total=12.97TiB, used=12.96TiB
System, DUP: total=8.00MiB, used=1.41MiB
Metadata, DUP: total=14.50GiB, used=13.81GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

共有が3つでファイル数が合計40万弱、フォルダー数が合計2万ちょいって感じだけど
メタデータが14.5GB中13.8GB使用となるとそろそろヤバいんだろうか？
今のところは全く問題らしい問題は発生してないっぽいが

**不明なデバイスさん** · 2018/05/10(木) 07:45:41.09

今となっては開発止まりかけてるbtrfsヒヤヒヤして使うより、実績のあるzfs使えたら良いのにと思うね
zfsはdedupさえ使わなければ安定した良い子

**不明なデバイスさん** · 2018/05/10(木) 10:12:25.20

COWのONOFFでメタデータのサイズがこんなに違うらしい

http://mevius.5ch.net/test/read.cgi/hard/1520518034/96-97
>ReadyNAS 528X　チェックサム有効 BitRot・スナップショット無効（COW無効）
>Overall:
>Device size: 43.64TiB
>Device allocated: 28.60TiB
>Device unallocated: 15.04TiB
>Device missing: 0.00B
>Used: 28.46TiB
>Free (estimated): 15.18TiB (min: 7.66TiB)
>Data ratio: 1.00
>Metadata ratio: 2.00
>Global reserve: 45.41MiB (used: 0.00B)
>Data,single: Size:28.60TiB, Used:28.46TiB
>/dev/md127 28.60TiB
>Metadata,DUP: Size:1.00GiB, Used:287.50MiB
>/dev/md127 2.00GiB
>System,DUP: Size:8.00MiB, Used:3.00MiB
>/dev/md127 16.00MiB
>Unallocated:
>/dev/md127 15.04TiB

>COW有効無効によりメタデータが桁違いに肥大化

>使用20.72TiBに対してメタデータ42.98GiB
>Metadata,DUP: Size:426.50GiB, Used:42.98GiB
>/dev/md2 853.00GiB

>使用28.46TiBに対してメタデータ287.50MiB
>Metadata,DUP: Size:1.00GiB, Used:287.50MiB
>/dev/md127 2.00GiB

**不明なデバイスさん** · 2018/05/10(木) 10:25:35.70

>>443
そう言うならext3だろ
ext4は遅延アロケーションの問題もあったし、extの中ではまだ新参

**不明なデバイスさん** · 2018/05/10(木) 10:31:00.23

ところでbtrfsの領域を強制的にext4でフォーマットしちゃうとどうなるんだろうね？
ボリューム拡大時にはエラーになりそうだけど。

**不明なデバイスさん** · 2018/05/10(木) 12:33:26.85

良くわかってないけど、バランスを定期的に実行すればいいんだろうか？
https://blog.fuga.jp/?p=1074

**不明なデバイスさん** · 2018/05/10(木) 15:42:15.18

バランスは一時的にほんの少し改善するだけですぐに元に戻る
時間かけて実行するだけ無駄

**不明なデバイスさん** · 2018/05/10(木) 15:47:39.84

まあ気休め逝くときは何やっても逝く

**不明なデバイスさん** · 2018/05/10(木) 15:50:35.29

>>447
なるほど、とても参考になった
System と Metadata は二重化されているから、倍の容量食うわけだな

>>453

"btrfs filesystem df /Volume/" の、
Data + System * 2 + Metadata * 2 + GlobalReserve が、合計のデータ使用量ではなく、
"df" でも "btrfs filesystem df" でも見えないデータが存在していて（不具合が起きた場合のみ？）、
"btrfs filesystem show" をやると、上記の合計よりも膨大なデータが消費されていることもあるのか

scrub やれば治るとのことだけど、ReadyNAS 104 (RN10400) などの数年前のモデル (メモリ512MBぐらいのやつ) だと
スナップショット不使用・RAID 1・Bit Rot保護有効の 3TB の HDD の scrub するのに 2～3週間はかかるからなぁ
（フォーマットして、他のHDDにコピーすれば、全部で2日ぐらいで終わるからそっちの方が早い）

scrub が終わらない古いモデルなら、Bit Rot保護もスナップショットも使わない方が良さげだね
とくに、Bit Rot保護は、初回有効にするときに「このモデルでBit Rot保護を使うとパフォーマンスが低下する」みたいな
警告ダイアログが表示されるので、NETGEAR 的にも非推奨だしな。

**不明なデバイスさん** · 2018/05/10(木) 16:29:13.75

>>433はメタデータの割り当て領域に空きが無くなってメタデータが書き込めないためディスクフルエラー
>>453はBtrfsがデータの空き領域も占有し空き領域を食いつぶしていることから起きているディスクフルエラー
同じディスクフルエラーでも原因は違う

**不明なデバイスさん** · 2018/05/10(木) 16:33:34.61

http://yskwkzhr.blogspot.jp/2017/04/if-you-use-btrfs-for-Dockers-storage-be-aware-of-free-blocks.html
> あらためて Docker のドキュメントをみてみると btrfs を使う場合のプラクティスとして balance を
> cron で定期的に実行するように書いてある事に気づきました。

**不明なデバイスさん** · 2018/05/10(木) 21:43:08.74

結局回避方法はなし？

**不明なデバイスさん** · 2018/05/10(木) 23:43:40.20

メタメタデータだな

**不明なデバイスさん** · 2018/05/11(金) 05:55:17.87

>>459
>>437

**不明なデバイスさん** · 2018/05/11(金) 10:42:09.35

528X買って10TB8本突っ込んでRsyncで戻したが
スナップショットが容量バカ食いで、ディスクを食い潰してアクセス不能に
結局初期化してスナップショット無効にしてRsyncで戻した
バックアップと同じくらい容量喰うスナップショットて何なんだよ
俺はRsyncでいいわアホらしい

**不明なデバイスさん** · 2018/05/11(金) 12:16:15.66

スナップショットの意味わかってる？

**不明なデバイスさん** · 2018/05/11(金) 12:21:49.73

日常のちょっとした風景の写真ですよね

**不明なデバイスさん** · 2018/05/11(金) 12:52:38.16

>>463
説明お願いします

**不明なデバイスさん** · 2018/05/11(金) 13:22:26.01

更新の多い状態でスナップショットONにしたら
昔のバックアップでいう増分バックアップと同じだけ容量食うからな

間隔と期間を十分に調整・設計しないと無駄になる

まれにソース管理のSubversionとかの置き場をNASにしてスナップショット取る馬鹿も居るからな

**不明なデバイスさん** · 2018/05/11(金) 13:23:07.57

初期化は無駄な作業だったな

**不明なデバイスさん** · 2018/05/11(金) 15:22:07.44

>>462
528X買うような人間がこんなことするかな？

**不明なデバイスさん** · 2018/05/11(金) 15:49:59.12

ミリネジとインチネジの見分けが付かず付属のミリネジをそのまま3.5インチHDDに使っているようなお馬鹿さんが526X、626X、628Xを使っているくらいですし

**不明なデバイスさん** · 2018/05/11(金) 17:14:04.25

>>468 金だけ持ってる無知は多いだろ

**不明なデバイスさん** · 2018/05/11(金) 18:55:28.40

金だけ持ってるならQNAPとか買った方が良いのではないか？

**不明なデバイスさん** · 2018/05/11(金) 19:41:43.82

やっぱQNAP>Synology>NETGEARって感じ？

**不明なデバイスさん** · 2018/05/11(金) 19:46:08.43

母の日セールで親孝行しよう。

▽NETGEAR▽ReadyNAS 8ベイNAS(ディスクレス) 1000BASE-T×4 RN42800-100AJS
│89,800円(税込)+期間限定:9,820円割引 = 79,980円(税込)
│【ご提供台数:15台】
└→ https://nttxstore.jp/_II_NG15766518?LID=mm&;FMID=mm

▽NETGEAR▽ReadyNAS 528X 8ベイNAS(ディスクレス) RN528X00-100AJS
│127,980円(税込)+期間限定:38,000円割引 = 89,980円(税込)
│【ご提供台数:35台】
└→ https://nttxstore.jp/_II_NG15663013?LID=mm&;FMID=mm

**不明なデバイスさん** · 2018/05/11(金) 20:38:54.31

BitRot保護ON、半年に1回スクラブ実行してるんだけどもしかしてあかんのか・・・？
そこに魅力感じたのにそれがダメとなると買った意味ががが

**不明なデバイスさん** · 2018/05/11(金) 20:59:37.98

問題が出てるのはごく一部じゃないかね

**不明なデバイスさん** · 2018/05/11(金) 21:11:50.72

>>474
問題が起きていないならいいし、特にスクラブやって不具合起きないならスクラブは定期的にやった方が良い（やらない方がゴミデータが貯まって不安定になる可能性が高い）

それとは別として、消えていいデータ以外なら、ReadyNAS に限らず RAID 以外にバックアップ取っておいた方が良いぞ
バックアップ用のHDDが無い場合、
例えば HDD 2台なら RAID 1でミラーリングするより、RAID無しの JBOD 2台別管理にして定期的にバックアップした方が安全性が高い
ミラーリングはファイルシステムの不具合などでアクセス不能になったときに復旧できないからね

RAID かバックアップの二者択一なら、バックアップが良い
無論、両方やるのが一番良いけど

特に RadyNAS が採用しているファイルシステム Btrfs は不安定で実績がなく、メタデータが壊れると各種データ復旧ソフトで復旧できないのは勿論、
データ復旧の専門業者でも復旧可能な業者は少ないと思われる
また、HDD (物理) に問題がなくても、ある日突然ファイルシステムが破壊されてデータが読み取れなくなったという人も居る

**不明なデバイスさん** · 2018/05/11(金) 21:37:00.20

なんで ID:60puc4Ku が目の敵にされてるの？

**不明なデバイスさん** · 2018/05/11(金) 21:48:48.88

どこにでもマウント取りたがる人はいるものさ

**不明なデバイスさん** · 2018/05/12(土) 04:58:43.16

>>476
> 特に RadyNAS が採用しているファイルシステム Btrfs は不安定で実績がなく、メタデータが壊れると各種データ復旧ソフトで復旧できないのは勿論、
> データ復旧の専門業者でも復旧可能な業者は少ないと思われる

Btrfsの仕組みを知らないで思い込みで批判してるやつ。
Btrfsはメタデータを2重化しているのでそこらのファイルシステムよりメタデータ破損の危険性は相当低い。
富士通などが書き込み中に強制システムダウンなど実験しBtrfsはデータ破損がなかったことを確認している。

**不明なデバイスさん** · 2018/05/12(土) 08:02:36.45

>>479
そういう外的要因での破損じゃなく、バグ的な要因での破損の話をしてるんじゃないの？
二重化しててもどっちも壊れた内容で更新されたらどうにもならないでしょ。

**不明なデバイスさん** · 2018/05/12(土) 08:21:37.00

そういうバグがbtrfsに存在すんの？
仮説の話するならいくらでもできるけど
Btrfsは復旧できないって言っている根拠も不明すぎるんだけど

**不明なデバイスさん** · 2018/05/12(土) 08:45:12.25

8ドライブタイプ縦長だけど、横にしても大丈夫？

**不明なデバイスさん** · 2018/05/12(土) 09:26:07.23

>>482
HDD自体は縦置き横置きどっちでもいけるから大丈夫じゃない？
とはいえ横置きにすると設置面積食うからメリットがないと思うけど

**不明なデバイスさん** · 2018/05/12(土) 15:47:44.09

>>479
メタデータの破損は、Btrfsのバグが原因なので、二重化してようが無意味。

> そして最も我慢ならないのが不安定さ。
> 昔、こじまみつひろさんなんかもいきなり読めなくなって嘆いていたが、
> unstableが取れた今でさえ、そういうことが稀によくある。
> そもそもディスクレイアウトが公開されておらず、「ソース読んで直接理解してね」という状況なので、
> 読めなくなる＝復旧不可能というお寒い状態。
> Btrfs RAIDかけていようがどうしようが、いきなり読めなくなるので冗長性など無意味。
> しかもカーネルが刺さるだとか、IOエラー吐くなんてのは、稀にどころか日常茶飯事。
> Btrfsの使用は、もはやtaints kernel。
https://srad.jp/comment/3257829

なお、こじまみつひろさんは、Linuxディストリビューションの一つの Plamo Linux の開発者で、
技術評論社で Linux関係の書籍を執筆している人なので、良く分かってない素人ではない。

**不明なデバイスさん** · 2018/05/12(土) 15:48:02.50

> 手元ではテストを兼ねて、1月ほど前からBtrfsをroot fsにした環境をイジってるけど、ここ数日で3、4度、原因のよく分からないクラッシュに見舞われた。
> だいたい発生するパターンは同じで、タイマー録音のスクリプトを実行してBtrfs上にMP3のデータを書き込み続けながら、
> NFS上の小さなファイルをローカルにマウントしているExt3なパーティションに移動させていると、
> 突然カーネルがストールしてしまう、という感じ。
> このトラブル自体は、別パーティションから起動して、最新版のbtrfsckを使うことで回復できたのだけど、どうもBtrfsは、ファイルシステムの使用量が増えてくると不安定になりがちな印象。
> 多分、テスト用に使っているパーティションが50GBくらいと小容量なせいもあるのだろうけど、
> ファイルシステムの使用量が6割を越えると、空き領域を探す処理が重くなるのか、反応速度が悪くなってくる感じがするし
> psコマンドで見るとカーネル内部のbtrfs関係のスレッドが大量発生しているのもあまり気持ちいいものではないところ。
http://plamo.linet.gr.jp/wiki/index.php?cmd=read&;page=diary%2FKojima%2F2011-11-11&word=Btrfs

> Plamo用パッケージのソースコード置き場とコンパイル用の作業環境に、ここ半年ほど使っていたBtrfsのパーティションがマウントできなくなってしまった。
> カーネルを最新の3.5.3に上げても、btrfs-progsを最新版にしてもダメみたい。
> 最後の望みをかけて btrfs-restore でファイルシステムの中身を取り出そうとしてもダメだった。
（略)
> 半分はテストのつもりで、NFS経由で32ビット機のコンパイル作業にも使っていたので、ファイルシステムへの負荷はかなり高かったのかも知れないけど、
> 特に目立った予兆もなしに、マウントや復旧できないレベルにまで壊れてしまうというのは、
> 「実用的に使うには難あり」という評価になりそうだな。
http://plamo.linet.gr.jp/wiki/index.php?cmd=read&;page=diary%2FKojima%2F2012-09-09&word=Btrfs

**不明なデバイスさん** · 2018/05/12(土) 16:00:46.04

>>481
> Btrfsは復旧できないって言っている根拠も不明すぎるんだけど

データ復旧業者は、ハードウェアの破損ならHDDを分解して中のディスクを、同じ型番の別HDDにクリーンルームor
クリーンブースで移植して読み出すのが基本で、論理的な破損なら復旧ソフトを使って読み出すに過ぎない

Btrfs は、btrfs-restore で駄目だったら、データ復旧ソフトが存在しないから、
Btrfs のメタデータ等の論理的な破損の場合、Btrfs のソースコードを読んで復旧ソフトの制作から始める必要があるので、
100万や200万の予算じゃあデータ復旧は不可能

何故、Btrfs に対応しているデータ復旧ソフトが存在しないのか
それは、まずシェアが少ないので、製作費のもとをとるのが困難
そして、Btrfs はそもそもディスクレイアウト等のドキュメントが公開されていないので、復旧ソフトを作るには
ソース読んで直接理解するしかなく、非効率だから

あと、「根拠も不明」とのことなのでもっと具体的に書くと、特殊なRAIDアレイ装置やマイナーOSにも対応している
国内最大手のデータ復旧業者のページを見ても、
https://www.ino-inc.com/service/area.php#format
> 対応フォーマット
> FAT16 ／ FAT32 ／ NTFS ／ HFS ／ HFS+ ／ EXT2 ／ EXT3 ／ UFS
とあり、Btrfsはそもそも受け付けていない

**不明なデバイスさん** · 2018/05/12(土) 16:19:47.64

>>484
>昔、こじまみつひろさんなんかもいきなり読めなくなって嘆いていた
昔と言っているし現在もこじまみつひろさんがメタデータが破損すると書いていない
その後の記載はこじまみつひろさんのレビューではなくAnonymousが言ってるだけ

>>485
2011年とか古い情報だしどこにもバグが原因でメタデータが破損したって書いていない

**不明なデバイスさん** · 2018/05/12(土) 16:23:28.98

そもそもbtrfsがそれほどまでに不安定なら今頃このスレは
ユーザーからの不具合報告だらけじゃないのか？

**不明なデバイスさん** · 2018/05/12(土) 16:28:10.97

ファイッ！

**不明なデバイスさん** · 2018/05/12(土) 16:46:02.68

>>486
>あと、「根拠も不明」とのことなのでもっと具体的に書くと、特殊なRAIDアレイ装置やマイナーOSにも対応している
>国内最大手のデータ復旧業者のページを見ても、
>https://www.ino-inc.com/service/area.php#format
>> 対応フォーマット
>> FAT16 ／ FAT32 ／ NTFS ／ HFS ／ HFS+ ／ EXT2 ／ EXT3 ／ UFS
>とあり、Btrfsはそもそも受け付けていない

https://www.value-press.com/pressrelease/201098
データ復旧11年連続国内No1のデジタルデータリカバリーがRAID復旧の最新復旧技術と設備を海外より導入。RAID機器の復旧速度が10倍以上に！

【どんなファイルシステムも対応します。】
使用するOSなどによって使用されるファイルシステムは様々ですが、一般的なNASやサーバーで使用されるNTFS、XFS、EXT3/4といったファイルシステムから、
最近ご依頼の件数が増加しているGPFS、『BtrFS』、VMFSやZFSなどの非常に複雑なファイルシステムすべてに対応が可能です。

Btrfsを受け付けていないと証拠とした業者さんBtrFSに対応ってプレスリリース出していますね

**不明なデバイスさん** · 2018/05/12(土) 17:06:18.21

ID:a+x/GFYQは対応フォーマットにext4が無いことを疑問に思わないほどバカなのだろうか

**不明なデバイスさん** · 2018/05/12(土) 17:38:05.51

データ復旧ソフトを書く人なら、なおさらドキュメントなんてものを盲信しないできちんとソースを参照すると思う。
ドキュメントが存在しないというのもよくわからん。
btrfs.wiki.kernel.org の Btrfsdesign とか Datastructures のページみれば、概要はわかるし、これとソースを併せて読めば少なくともパッチ書ける程度にはなるよ。

とはいえ、安定してないと言うのには同意。
ここ数ヶ月でも、相当致命的なバグに対する修正が入ってるんだけど、当然今のReadyNASOSには反映されてないだろうし。
Linux のAPI変更に追従するための修正がほとんどというほどに枯れる時期は相当遠い。

>>451
ext3 はもうソースツリーから落とされてる(2015)。
わざわざ今のカーネルにバックポートするのは漢というよりは蛮勇な域かと。

>>491
そうなんだと思う。

**不明なデバイスさん** · 2018/05/12(土) 18:20:00.85

>>490
そうだったのか
貴重な情報をありがとう
大手業者の癖に「対応フォーマット」のページすら古いまま放置とか糞すぎるな

>>491
言われてみれば確かに ext4 が無かったわ
今時Linux系に対応してて ext4 が無いなんてありえないからな

**不明なデバイスさん** · 2018/05/12(土) 18:21:37.79

なんかまた長文レスの応酬が続くのかしら

**不明なデバイスさん** · 2018/05/12(土) 18:33:09.48

>>494
痛いとこ疲れてレスバトルに負けたので僕は撤退します＞＜

**不明なデバイスさん** · 2018/05/12(土) 18:33:49.22

×疲れて　〇突かれて

**不明なデバイスさん** · 2018/05/12(土) 18:49:19.87

自分が無知なのを業者の所為にし出したよ
データ復旧+NETGEARでググるとOS6モデル対応のデータ復旧企業が出てくるのに
結局ID:a+x/GFYQが根拠のない思い込みで荒らしていただけじゃん

**不明なデバイスさん** · 2018/05/12(土) 19:26:39.13

>>497
本人も間違い認めて撤退したんだからもういいじゃん

btrfsに問題が多いのは確かなんだろうけど、普通にReadyNASを使ってる限り
実用に耐えないほど不安定なようには見えんね
もしそこまで不安定ならファイルシステムの問題に起因するトラブル報告で
ReadyNASスレは埋め尽くされてるはず
少し前に上で出てたメタデータ肥大化の問題は要注意っぽいけど

**不明なデバイスさん** · 2018/05/12(土) 19:58:18.90

間違い認めたんじゃなくID:a+x/GFYQのデタラメなレスを完全に論破され業者の所為にして逃げただけじゃん

>何故、Btrfs に対応しているデータ復旧ソフトが存在しないのか
>それは、まずシェアが少ないので、製作費のもとをとるのが困難
>そして、Btrfs はそもそもディスクレイアウト等のドキュメントが公開されていないので、復旧ソフトを作るには
>ソース読んで直接理解するしかなく、非効率だから

こんな自信満々にレスしておきながら

**不明なデバイスさん** · 2018/05/12(土) 20:08:33.57

家庭で使うレベルでなら安定してるとは思う。
業務で使えるかと聞かれたら、自分だったら導入したくないレベルの安定性だと思う。
ネットギアは、業務用NASとしてちゃんと社内で自分たちも使ってるんだろうかと思う程度には使い物になってない気がする。しれっとEMCとかNetApp入れてるんじゃないだろうか。

ラックマウントモデルを業務用として導入してる人のコメントをみたい。

**不明なデバイスさん** · 2018/05/12(土) 20:20:19.10

とりあえず長文書く奴はNGでOK

**不明なデバイスさん** · 2018/05/12(土) 20:20:41.26

>>499
ID:a+x/GFYQが余計なこと言って自滅したのとは別として、
Btrfsのファイルシステムの論理障害に対応しているデータ復旧ソフトってあんの？
あるなら教えて欲しいぐらいなんだが

データレスキュー会社のBtrfs対応ってのは
HDD磁気ヘッドやスピンドルモーター等の物理障害起こしたHDDがBtrfsでフォーマットされててもデータを読み出せるって意味で
Btrfsのファイルシステムやメタデータが論理破損したHDDのデータを回復できるって意味じゃないと思うぞ

**不明なデバイスさん** · 2018/05/12(土) 20:23:06.14

デフラグバグやディスクフルバグは一向に修正しないのは知っているが古いソースでBtrfsを叩くのは間違ってる

**不明なデバイスさん** · 2018/05/12(土) 20:34:59.17

>>502
ないと思う。
btrfsprogs 以上のユーティリティを書ける人なら、それなりに btrfs ツリーのコミットログに名前上がってるだろうけど、それっぽい人は居ないから。

自分がメタデータ壊れたときは、 btrfs rescue と btrfs-find-root でほぼあらかたサルベージ出来た。

**不明なデバイスさん** · 2018/05/12(土) 20:35:28.40

>>503
そうだな
付加機能が不安定なだけで、最近のBtrfsは基本部分は割と安定している
コピーオンライトとスナップショットとデフラグさえ使わなきゃBtrfsでも不具合は殆ど起きないと思う
この3つを使わなないならext4で良くね？とは思うけどBtrfs強制のReadyNAS6系でもこれらをOffにすれば安定運用が可能

**不明なデバイスさん** · 2018/05/12(土) 20:41:54.77

>>505
利用率75パーセント(目安)超えたらディスク増設と、X-RAID での大容量ディスクへの交換はしないも追加したほうがいい。

**不明なデバイスさん** · 2018/05/12(土) 20:45:28.17

>>506
＞X-RAID での大容量ディスクへの交換はしないも追加したほうがいい

これやると何か問題起きるのか？

**不明なデバイスさん** · 2018/05/12(土) 20:59:44.96

>>507
内部的に lvm のボリュームが増える。
そうすると既存のボリュームと追加されたボリュームそれぞれにメタデータが置かれるようになる。
経験上、こうなるとメタデータの領域確保できなくなってファイルシステムがリードオンリーになり安い。
そしてこの状態を標準のUIから確認する術が提供されてない。
ssh 経由で各lvmボリュームのヘルスチェックしないといけなくなって、アプライアンス買った意味無いになる。

**不明なデバイスさん** · 2018/05/12(土) 21:15:22.29

自分は利用率が80%を超えたらスナップショットを自動削除するようにしてるわ

**不明なデバイスさん** · 2018/05/12(土) 22:04:06.74

>>502
>論理的な破損なら復旧ソフトを使って読み出すに過ぎない
そもそもID:a+x/GFYQが復旧ソフトで復旧してるだけとレスしてドヤ顔でリンク張った復旧業者は復旧ソフト使わず人力で解析して復旧してるって書いてあるじゃん

>復旧作業としては、専用機器にてハードディスク内の磁気情報を読み出します。
>読み出したセクタ情報から、数字の羅列を職人が目視で確認しながら独自の計算式を使用してファイルシステムの構成とファイルの復元を行います。
>１セクタあたり1024文字。１ＧＢだと２００万セクタ　約20億文字になります。その中から、壊れている箇所を割り出して修復する為には、細かい手作業が必要になります。
https://www.ino-inc.com/symptom/whyhdd.php

>当社では、RAID情報はもちろん参考にしますが、RAID情報だけでなく、HDD内のデータ配列からRAIDレベルやHDDの台数、当該HDDのRAID内での番号を割り出し、クローンHDDを使用して仮想的にRAIDを組み直します。
>簡単に書いてはいますが、実際の作業は非常に地味で、根気のいるものです。 0と1で成り立っているデータを一旦16進数に変換し、その文字列1つ1つを専門の技術員が目で追っていきます。
>デジタルデータの復旧ですが、復旧方法は非常にアナログです。しかし、その文字列1つ1つを見て、どこがおかしいか「判るか否か」が復旧できるかできないかの違いです。
>復旧ソフトを使用してのデータ復旧と異なる、当社独自の復旧方法です。サーバ機器のメーカーや、HDDのメーカーでも、このような作業はできません。
https://www.ino-inc.com/raid/enterprise_new/

**不明なデバイスさん** · 2018/05/12(土) 22:07:28.90

>>508
lvm じゃない。 md だった。

**不明なデバイスさん** · 2018/05/12(土) 23:20:37.61

>>500
https://community.netgear.com/t5/Using-your-ReadyNAS/RN3312-BTRFS-operations-are-completely-hung/td-p/1320736
RR3312を使っている人
スナップショットを削除したらbtrfsプロセスがCPU100％占有して共有フォルダにアクセスできないフリーズすると怒り狂っています

**不明なデバイスさん** · 2018/05/12(土) 23:36:48.26

たかだかスナップショットで問題が出るような状況だと
将来的に重複除去なんかやらせたらどうなることやらｗ

**不明なデバイスさん** · 2018/05/12(土) 23:45:25.80

>>508
ソースに、
warning(”DUP is not recommended on filesystem with multiple devices”); と言うのを見つけた。
Netgear がfs開発者の警告無視して複数デバイス(md127,md126,...)上で metadata を dup するように製品作ってるのが問題のよう。
X-RAID での大容量HDDへの交換は鬼門という経験則は当たりだったぽい。
もちろん、交換だけじゃないなくて容量の違うHDDを使ったX-RAIDを構築しても同じだと思う。

**不明なデバイスさん** · 2018/05/13(日) 00:06:24.57

>>512
ああ、悲惨そうだ…。

**不明なデバイスさん** · 2018/05/13(日) 00:20:46.34

>>514
4.5.1でその制限は撤廃しているが

**不明なデバイスさん** · 2018/05/13(日) 00:37:17.78

>>516
4.5.1 まではその状態を許さなかったのを、4.5.1 から警告付きで許すようにしたんであって、現状(4.16)でも警告出すレベルの信頼性であることには変わりがないと思う。

**不明なデバイスさん** · 2018/05/13(日) 01:49:35.02

そろそろ専用スレでやって欲しいわ

**不明なデバイスさん** · 2018/05/13(日) 05:49:15.28

>>508
複数になる md を lvm で束ねた上に btrfs が乗ってるわけで、btrfs は md の構成なんて知りようが無いと思うが、本当にメタデータを md 毎に意図的に配置するなんて器用なことやってるの？
linux なんてブロックデバイスの物理構造を何層にも自在に重ねられるが、btrfs はその構造のどの単位にメタデータを置くの？
readynas独自のカスタマイズ？

**不明なデバイスさん** · 2018/05/13(日) 09:18:21.80

>>484-485
>メタデータの破損は、Btrfsのバグが原因なので、二重化してようが無意味。
ソースにBtrfsのバグでメタデータが破損すると記述は在りませんでした

>>486
>論理的な破損なら復旧ソフトを使って読み出すに過ぎない
データ復旧業者は復旧ソフトを使っていませんでした

>Btrfsはそもそも受け付けていない
受け付けていました

よくここまでウソばっかりつけるなと関心
なぜ彼はすぐバレるウソをついてまでbtrfsをたたきたかったのか

**不明なデバイスさん** · 2018/05/13(日) 10:00:20.36

>>519
lvm で束ねてない。言い間違い。 >>511
md の上に btrfs を作っていて、 X-RAID での拡張は追加領域を使ってさらに md を作って btrfs device add してる。
なので btrfs device usage すると、容量の違う
md が複数(通常のユースケースだと多くて3つ程度)存在する。
4Tx4 -> 6Tx4 -> 8Tx4 の様に構成を変えると、
16T(12T) と 8T(6T) と 8T(6T) の md が btrfs のメンバデバイスになる。(カッコ内はmd でRAID5かけたあとの実容量)

そして、最初に存在していた md 上の metadata 領域が足りない時や、容量の比率に応じて他の md の上にも metadata を作り出す。
metadata を DUP してるのは readynas の仕様であり、ユーザに提供されている UI では single 化はできないようにされている。

**不明なデバイスさん** · 2018/05/13(日) 10:32:38.58

↑ガイジの皆さん、専用スレたててあげようか？
スレタイくれればすぐにやってやるよ

**不明なデバイスさん** · 2018/05/13(日) 11:14:18.99

お前が居なくなれば？

**不明なデバイスさん** · 2018/05/13(日) 11:28:14.57

>>513
https://mevius.5ch.net/test/read.cgi/hard/1520518034/91
>91不明なデバイスさん2018/03/17(土) 19:59:03.41ID:SdLQIslQ
>大雑把に言えば
>
>削除ファイルの変更前変更後等々の紐付けを確認する
>　　　　↓
>紐付けられたデータから削除ファイルの情報を消して新たに紐付けし直した紐付けデータを作る
>　　　　↓
>古い紐付けデータを消す
>　　　　↓
>削除ファイルを消す

>この作業を並列ではなく１つずつちまちまと実行してる
>紐付けられたデータ自体が削除対象に含まれていても上記の処理を一旦実行してる
>はっきり言えば効率が悪いとしか言いようがない

何度も出ているが原因はメタデータの肥大化。
スナップショットを大量に削除するときにメタデータの書き換え処理も大量に行われそれが負荷の原因。
耐障害性確保のため一度にまとめて処理ができない弊害。
メタデータもCoW動作なので断片化の影響をもろに受けてしまう。
重複除去もメタデータに情報記録されるから増えれば同じ事。

**不明なデバイスさん** · 2018/05/13(日) 11:28:35.03

>>521
いや束ねてるよ。
実際にログインして確かめてみろよ。
おれは linux pc にディスク繋いでサルベージする手順を一通り確認してるから間違いないよ。
この辺はOS4と変わらん。
暗号化してるとさらに luks が入るくらい。

**不明なデバイスさん** · 2018/05/13(日) 11:56:34.24

>>525
OS4 と変わってる。
OS4 のころは、 HW-RAID + LVM (MIPS) や、 MD + LVM(x86) だった。(ARMは持ってないから知らない)
OS6 (古いのは知らない 6.4 以降位から現在) はボリュームの管理とスナップショットを LVM から btrfs に変えてる(少なくとも手持ちのx86は2台とも)。

OS6 は bitrot 対策で Netgear 独自のコードが加わってて、それが btrfs が md に直に乗ってる構成に依存した作りになってるから、手持ちの ReadyNAS に bitrot 保護機能が付いてるなら btrfs + md (without LVM) の筈だよ。
単に fs を ext4 から btrfs に変えただけじゃない。

> おれは linux pc にディスク繋いでサルベージする手順を一通り確認してる
あなたも試練をくぐり抜けた人か。

**不明なデバイスさん** · 2018/05/13(日) 12:01:52.41

いい加減にしろ、糞オヤジども

**不明なデバイスさん** · 2018/05/13(日) 12:56:22.95

>>525
# cat /etc/os-release
PRETTY_NAME="ReadyNASOS 6.9.3"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/";
SUPPORT_URL="http://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";
# lvs
-bash: lvs: command not found
# which lvs
# dpkg -l | grep lvm
# btrfs device usage /data
/dev/md126, ID: 1
Device size: 9.07TiB
Device slack: 0.00B
Data,single: 9.05TiB
Metadata,DUP: 18.00GiB
System,DUP: 16.00MiB
Unallocated: 5.00GiB

/dev/md127, ID: 2
Device size: 1.82TiB
Device slack: 0.00B
Data,single: 1.81TiB
Metadata,DUP: 2.00GiB
Unallocated: 4.76GiB

**不明なデバイスさん** · 2018/05/13(日) 13:07:55.18

そんなあなたにlsblk

**不明なデバイスさん** · 2018/05/13(日) 13:43:48.96

>>514
X-RAID2なら大丈夫？

**不明なデバイスさん** · 2018/05/13(日) 14:42:33.61

おもろい議論だから続行してくれ
ReadyNASとBtrfsの関係からズレなければＯＫ

手持ちのOS6機はX-RAID2だけだから気になるなぁ >> 530
メタデータの問題ならダメなのだろうけど

メタデータを含めた残容量の気を付ける、メタデータをシュリンクさせる
ような処理は極力行わない、でＯＫ？

**不明なデバイスさん** · 2018/05/13(日) 15:57:13.99

X-RAIDで拡張した後でもメタデータ領域は拡張されるよ
チャンクを増やすだけだし
ただデータとメタデータの不均衡が起きたときのために
バランスを定期的に実行してねとNETGEARが言っている

**不明なデバイスさん** · 2018/05/13(日) 16:00:53.20

>>462
rsync なら、bwlimit オプションつけて、30MB/s くらいでリミットかけると割と安全。
半年くらい前に似た経験して

>>530
現行機種で X-RAID1 の箱って存在してないはず。
自分は X-RAID2 のことを指して X-RAID と言ってる。
HDDを追加していくのは割と安全。 HDD を大きいのに変えたり、容量が揃ってない組み合わせはそれなりに危険。

**不明なデバイスさん** · 2018/05/13(日) 16:11:36.33

>>529
パッケージ入れるのは抵抗あるなあと思ったんだけど、標準で入ってた。便利だねこれ。

>>532
WebUIでバランスをスケジュールすると実際にどんなコマンドが発行されるか分かる？わかるのなら是非教えてほしい。 WebUI だと、バランスもデフラグも実際に何をしてるのかわからないのが不安。
自分は不安だから CLI で手打ちしかしてない。

>>531
なに毎も、一気に大量に行わない。

**不明なデバイスさん** · 2018/05/13(日) 16:23:34.00

なんで俺に聞いてくるのか分からん
知りたければ直接自分でNETGEARに聞けばいいだけだろ

**不明なデバイスさん** · 2018/05/13(日) 16:27:58.15

>>535
気力がわかない。
自分は既に問題解決しちゃってるので動機もない。

**不明なデバイスさん** · 2018/05/13(日) 16:59:43.30

X-RAID2ならX-RAID2って最初から書いとけや猿ゥ

**不明なデバイスさん** · 2018/05/13(日) 22:17:56.18

じゃあもう黙って部屋の隅で口開けて埃云々