【NAS】 FreeNAS/NAS4Free総合 【FreeBSD】 Part2
■ このスレッドは過去ログ倉庫に格納されています
FreeNAS : Open Source Storage
http://www.freenas.org/
NAF4Free : The Free Network Attached Storage Project
http://www.nas4free.org/
PCをNAS化するFreeBSDベースのディストリビューション
バックアップや物置にﾏﾀｰﾘ語りましょう
何かエラーのことを質問するなら、まずログを確認
そこには重要なキーワードが書かれているはずですよ
前スレ
【NAS】 FreeNAS/NAS4Free総合 【FreeBSD】
http://mao.2ch.net/test/read.cgi/mysv/1446904490/ メモリ32GにNVMe400GB全部L2ARCに振ってるけど別に重くなってないぞ >>665
SSDをキャッシュにしたらパフォーマンスの改善がされました、ということに何が不満なんですかね。 >>664
そのあたりは運用方法次第じゃない？
たかがNASとして使うかされどNASとして使うか？みたいな
うちの場合NAS4Freeをストレージ鯖としてすべてのファイルを一元管理してるので一番重要になってる >>657
このリンクの計算方法正しいの？
ZFS圧縮掛ける場合は1block=128kBがデフォルトレコードサイズな気がする。
512バイトは圧縮使わない場合とかどっかで聞いたような？
だから「ざっくり64ｋ」じゃなくて「固定で128ｋ」で計算すれば
１TB＝5G。
結構、現実的な数字じゃね？
てか、不満なら最初の設計で1ブロックを248KBとかにすれば良いんであって。 >>670
>dedupなら2TBで10GBとかでしょ。
あ、ごめんそう書いてるね。
何にしてもメモリと兼合いを検討するなら、ブロックサイズ調整すれば良いかなと。
究極の分散FSであるグーグルFSは1ブロック64MBらしいし。 ZFSの開発者はメモリ64GB未満の環境ではL2ARCを使うことを推奨していない
L2ARCは意外とメモリ消費が激しくARCに使える量が減ってしまうので >>662
以前テストしたときはECCの為にメモリを半分に減らしたマシンにSSD64GB+200GB搭載しても全く速度に寄与しなかったよ。
そもそもL2ARCはARCから溢れた物を表に影響出ない程度の速度で充填していくだけの物だから書き込みには一切寄与しない。
ZILは同期書き込みの時だけ此奴がログを引き受けるもんだから桁違いに速くないと此奴のせいで逆に遅くなる。
>>664
たかが、の基準が何処に有るかわからんけど、そういえる程度のNASにZFSを使う方が冗談でしょって話ではないかな。
サンが健在だった頃からZFSの運用はまずメモリ、性能上げる方法もメモリって言われるくらいメモリ第一よ。 そもそもエンタプライズ向けのファイルシステムなんだからたかが
NASと言われたらたかが64GB、な話。 今となってはその通りだが、zfsでた当時は
メモリ64MBとかそんなもんだった気が。
2TBのインメモリDBが出たときはすげえと思ったが、
それも確か7年前くらいか。 >>674
何時の時代のエンタープライズなんだよ？
サンが健在だったころのエンタープライズなら当時はxeonの結構
良い奴でもMAX32GBが多かったみたいだけど？
>以前テストしたときはECCの為にメモリを半分に減らしたマシンにSSD64GB+200GB搭載しても全く速度に寄与しなかったよ。
どっちかの実験が間違ってたとしか言いようがなくね？
速くなったと言った方が勘違いなのか、何も変わらないと言っている方の
実験方法が正しくなかったのか。 少なくともネットワークが1Gbps LANのままならば、ネットワークがボトルネックになって大量のメモリやSSD cache の効果はでてこない。 両方とも正しいという答えもある。そもそも比較するのが間違っているという答えも。
何せ測定環境も測定方法をそろえてない話だ。どっちが間違いとか以前の問題。 でもまあ普通に考えれば、SSD をキャッシュにしたら
HDDの速度は上がるんでね。 l2arcでセカンダリにキャッシュされるデータがメタデータだけになってましたー
とかいうオチじゃないだろうね・・。 >>679
SSD cache はランダムアクセスを効率化するとガイドにある。 >>679
同じデータを2回読まなければ上がらんだろ。 >>675
zfs出たの2004年よ。Win2003で64GB。64MBとか95年に一般でも64MBでしょ。
Sun ZFS Storage 7120の24GBで大量にファイル消して大変だったのを体感した時代があったけど、そこから考えれば64GBとか安く手に入るのはいい時代だよね。 出たのは頃のはそんなもんだけど、さらにメモリを要求する
dedupが入ったのが10年頃。
この辺出たサーバSunT4-1だけど最大メモリ512GBだから時代に合わせて
増し増ししていったんじゃ >>684
ちょっと悪いけどZFS語るときにdedupは除外して話してもらえないか？
あっちは、リンクで完全に必要なサイズが見積もれるんだからどうでも良いじゃん。
http://d.hatena.ne.jp/flageo/touch/20120318/p1
（必要なデータ量ｎTB） / (ブロックサイズ(デフォ128kB)) * ハッシュ(320byte)
重複排除使いたい人は、見込のデータ量からブロックサイズ決めれば、
自動的にこの機能に必要なメモリサイズは決定する。
使わない人はその分のメモリは必要ない。
で、それを除外しても、ZFSはメモリ食いなファイルシステムなの？？
そら、圧縮がほぼ外せない機能だから、普通のRAID5に比べれば要るのはしょうがない。
じゃあ、何GBなのさ？って話なんだが？8GBで運用してる人もいるんでしょ？ >>685
その説明ってZFSの仕組みから始めることになる板違いも良いところだけど
端的に言ってメタデータの操作が非常にコストが重いのでディスクに読みに行かないようにメモリ上に留めようとすると
実際に使用されているブロックとして1TBあたり1GBは必要って事になってるだけよ。
必要量に満たなくても特にトラブルにならないのは実際に使用されているブロック数をそのまま操作対象とする状況が発生してないからで
そのような操作は非常に大量の削除やデータセットの破棄に顕著だから日常的には問題にならない。 >>690
横槍やけど
自宅サーバースレって言うことを忘れないでほしい
何でもかんでもMaximumの状況を考える必要もない
必要な人はそうしたらいいだけで、他の人を罵るなんて人間性がおかしい こうじゃなきゃいけない！って言う感覚が強いのかな？
環境はひとそれぞれなんだけどね >>690
いやいや、
> 実際に使用されているブロックとして1TBあたり1GBは必要って事になってるだけよ。
この程度だったら別にいいよ。8TBの容量で8GBメモリ？
十分実用的じゃん。何でもかんでも64GBメモリ積め、ってのとはエラい違いだ。 メモリ搭載量もそうだし、SSDはメモリ積まないとなんの意味もないっていうのも、直感的にもホントかよって思う。 Dedup やるとして、メタデータをSSDに配置できるならまあまあ速いのでは。 >>696
NVMe SSDなら、パフォーマンス的にメモリと張り合えるかもしれんね。
でも、そんな都合の良いオプションは在るの？？ キャッシュされっぱなしのが速いてだけだから、遅くていいならどうでもいいって言われてるじゃない。
まともに使うならメモリがあればあるだけいいってのに対してなにが不満か一切わからん。 >>698
>自宅サーバースレって言うことを忘れないでほしい
って言われてるじゃん。 自宅サーバーて言われてたら搭載するメモリに制限がかかんの？
なければなけれで制限を受けて、あればあるだけ恩恵を受けるてのに対して自宅だからって言うのがどこにかかんの？ まあ、自宅だから妥協できる／自宅でも妥協したくなきゃメモリ積むてことにはなるだろうね。 >まともに使うならメモリがあればあるだけいいってのに対してなにが不満か一切わからん。
寧ろ、NASにメモリ在るだけ積まなきゃまともに動かないよ、って言い分に
何で納得できるのが良く判らん。そんなに糞コスト掛けて良いなら、
市販のNASサーバーかった方がマシじゃん。
仮に大量のメモリ積むことによってHDDでRAIDを構成しながらRAMDISKとは言わない
までもSATASSD並みの書き込み速度を実現する、とかなら分からんでもない。
そんな事は無いんでしょ？
だったらソコソコのメモリサイズでソコソコのパフォーマンスを実現してくれれば
それで良いよ。
重複排除に関してはバックアップ用途で使用するなら、凄いパフォーマンスを発揮する
事は理解したら、その点でメモリ消費するのは納得だ。 >そんなに糞コスト掛けて良いなら、市販のNASサーバーかった方がマシじゃん。
結論出たじゃん。 >>703
>>478,494,499,506,510,516,542,619,620
お前、この辺のどれかだろ？
相変わらず問題解決能力ゼロだねｗ 職場にFreeNAS持ちこんだ結果問題が起きてココに頼りに来たのが705 第一今問題なのは適切なメモリサイズの見積もり方法であって
>問題が起きてココに頼りに来たの...
とかいう解決策ではない。お前、話題がなんなのかさえ分かってないだろ？w
だから揚げ足取りしかできないｗ >>705
ブーメラン刺さってるぞ。解決結果書いてみろ >>710
タスクの進捗が全然読めてないのねｗ
freenasのインストールにUSBメモリを使用するか否か？
結論： >>556
freenasに必要なメモリ、その①
結論： >>685
freenasに必要なメモリ、その②
>>じゃあ、何GBなのさ？って話なんだが？8GBで運用してる人もいるんでしょ？
↑ 今の問題はここ。
これが終われば、見積もりに関してはほぼOK。後はパフォーマンスチューニング。
思い切り進んでるじゃん。で、お前ら(>>710,709,706)は問題の解決の何の役に立ったの？
揚げ足とってるだけだけどｗｗ
バカはおとなしく俺に感謝しとけよｗ。 >>711
強いて言えば>>694が本当かどうかって根拠の検証だね。
それに対して、>>703みたいに、糞みたいなレス返す奴がいるけど。
ホント役立たずだよ。 自分で問題解決しろよ。問題解決もできねーのか？無能。 >>713
揚げ足取りばっかの無能はおまえだろ？
大概にしろよ糞野郎ｗ
お前もう此処に来んな。
まともな回答出来ないROMるか、出て行けよ糞タコ野郎ｗ
能無しのお前と違って、俺はある程度ちゃんと回答をしてる。 >>702
出典忘れたのでソース出せなくて悪いが
どこかのサイトで検証した時にHDD-RAIDZ2+IB20Gbps構成で
シーケンシャル書き込みで800MB/sとかいうの見たことある
そのサイトの検証はストレージの検証じゃなくネットワークの検証だったので
1Gbpsと20Gbpsでの比較で当然だけど1GbpsNICでは100MB程度しか出てなかったけど
俺個人の環境だとUSB2で接続してる外付けHDDへの書き込みで100MB/sてのはあったな >>715
https://fefcc.net/archives/453
この辺り？20gbeじゃないけど。
まあ、額面通り評価して良いかは何とも言えんね。
diskmarkって事は同じデータを読み書きで計測したんだろうし。
そうなるとarcであれl2arcであれキャッシュが使われるだろうし。 ZFSをiSCIでマウントしてOSを入れるのであれ、単なる事務データを保存するのであれ、
「全く同じデータ」を何度も読み書きする事は、そうは無い。
例えばZFSニコニコ動画が採用してるらしいけど、ああ言った、Write Once Read Many
なサービスなら確かに威力を発揮する。
が、その方式が普通の家に入れるNASにマッチするかというと別の話。
だから額面通りは受け取れない、という極めて真っ当な感想を述べたら、それに対する
最初のレスが、>>718とか、もう、コイツに脳味噌は本当についてるのかと…。 >>716
そのサイトじゃなかったけど
そもそもの論点が大量のメモリが必要かどうか？なので
キャッシュが有効な状況で良くない？
キャッシュが効かない状況ではメモリ不要なんだし >>720
結局必要かどうかは運用方法次第としか言えんと思うのだが
このスレに限らないけど大抵極端な環境前提に論点がずれていくからな・・・
ZFSを有効に使うためには大量のメモリがあったほうが良いてだけでしょ
そこまでZFSの能力を使わなくても良い運用なら別にそこまでメモリ積まなくてもいいだけで
まぁ積まなくて良い運用ならZFSの必要性あるの？と話もあるけど
それこそ自宅鯖なんだし趣味や好みあるだろうから別にいいじゃんて話でしょ もうメモリネタ出すのやめませんか？変なのがいつきますので。 >>724
全然違うじゃん。
タブとスペースは本来のゴールとは一切関係ない好みの問題だけど、
メモリの問題は実務的な問題だ。
「無条件でZFSだから64GBないとまともに運用できないよ」と
「○□△の理由で8Gでも十分運用可能だよ」
は段違いだろ？やっぱレベルが………。 >>725
10年前は結局何を争ったの？そしてどういう結論に達したの？
そこで、まともな結論がでたのなら、
「無条件でZFSだから64GBないとまともに運用できないよ」と
「○□△の理由で8Gでも十分運用可能だよ」の
どっちかは居なくなってる筈だけど、何で今も争ってるの？
そもそも10年前と今じゃメモリ取り巻く状況が全然違うと思うんだが？
（10年前のコンシューマ用マザボはMAXでも大体16GB、今は64GBでも余裕）
何故同じ話題が継続するのかと…。 お互いがお互いを尊重し認めればいいだけなんだけど
俺が正義だ何も間違っていない、お前は馬鹿かって罵るやつが居るからおかしくなる >>722
だったら、そういう書き方をしろよ、よって話で。
俺の場合はこうだった、って経験則で書くのは全然構わないけど
思い切り間違った結論を、さも当然、ZFSなら当たり前の様に
書いてくる奴は一体なんなの？ SQLと同じでメモリに一回のったデータを消さないんでしょ。他で使われることがあるときに追い出されるからあればあるだけキャッシュにアクセスするし、なければディスクから読むだけで。
L2ARCあっても云々はメタデータがメモリ上にあるからメタデータのないデータがL2ARCにあっても使われないし意味ないよね。てことで。 >>733
全然そんなやり取りになってないじゃん。
その程度だったら何で>>672見たいな書き方するのさ？
それに対して>>662とか>>666とか、明らかに違う結果を
報告してるのにそれはスルーｗ
>L2ARCあっても云々はメタデータがメモリ上にあるからメタデータのないデータがL2ARCにあっても使われないし意味ないよね。てことで。
悪いけどそういう解説するときは1次ソース付けてくれない？
FreeNASでもOracleのZFSでも良いよ。 そこそこわかりやすい解説
https://people.allbsd.org/~hrs/sato-FBSDS20161129.pdf あとはiXsystemかOracleにでも問い合わせるといいと思う >>737
そう、俺もこれは読んだ。で、
知っておこう（２）：
Q：L2ARCを単純にデカくすればヒット率は改善するんじゃないの?
A：L2ARCを増やすと、耐えられないくらいメモリ消費量が増える
つまりL2ARCの容量 x 2.92%のメモリを消費！
? ＜朗報＞10.3, 11.0 以降は 1.59% の消費に減りました
これなら、一般的な家庭用で小さいSSD追加すれば>>662見たいな結論
になるのは良く判る。で、>>661とか、>>672見たいな結論はどっから出てくるのかと。 たった32GBのリードオンリーキャッシュで無条件に数倍に高速化出来るならWindowsのキャッシュソフトがあんなに足蹴にされないわ。
数倍やぞ。五割増しとかそんなんじゃ無くて最低でも3倍以上とかどれだけ盛ってんねん。
笑うわ。 >>740
キャッシュされていないデータがZFSから、LZ4でdecompressされて
データ取得されるのなら、数倍になったとしても別に驚きはしないと思うが？
勿論、この人の勘違いもあるだろうけど。
そもそも、ZFSのキャッシュの話を否定するのにwindows(NTFS)を持ってくるとか、
全然違う話だろ？ >>742
ほんと、もう良いよｗ
まともな根拠持って来いよｗ >>741
Windowsの話をしたのはキャッシュシステムは魔法の杖ではないという例えにすぎへん。
条件そろえて速度出ました！とか逆に条件全部外して速度出ません！ってどう違うねん。
キャッシュなんぞヒット率まともに出えへんかったらキャッシュ確認する分余計や。
それを多種環境ひっくるめて効く効かんの話とか笑うで。 L2キャッシュが素晴らしいものに見えてるようにお考えのように見えます。
索引(メタデータ)自体がメモリ上にあってキャッシュデータ(ARC)もメモリ上にあり、ARCは古いデータから順にL2ARCに逃します。
この際にメモリ少ないとARCのデータは高頻度でL2ARCに追い出され、ARCに戻るを繰り返しますがこの際IO(Read/Write/Delete)が発生します。L2側の速度は無限ではないのでL2ARC のキャッシュ読む際のリードにも影響が発生します。
L2ARCは書き込みキャッシュではありませんので >>662 のようななにかが早くなったという内容は自身が言うように根拠を添えてください。ZILである場合は論点から外れています。ZILは同期書き込みと関連するのであってメモリ容量と関係ありません。
上記ドキュメントを全部読んでこれくらいの理解ができない／それ以上を求めるならOracleかiXsystemに聞いてください。きっととても素晴らしい回答を求められるかと思います。
ここはzfsのメモリについて議論するためのスレじゃ無いですし、自分でzfsのスレ立てるべきです。
その際は自分の根拠に自身が言うOracleかiXsystemかFreeZFSあたりのドキュメントも添えるといいと思います。人だけに根拠を求めて自身は根拠のないものを理屈にするのは狂ってますしね。 >>744.745
もう、お前らの脳味噌は本当におかしいなｗ
「L2ARC使うのにメモリが64GB、必要と言う結論はどっから持ってきているのか？」と
聞いているのに、何で何倍も早くなるのがおかしいとか、L2キャッシュが素晴らしいとか、
変な方の話に持っていくの？
1回2回位なら見当違いのレスでも、突っ込んであげるけど、それに3つも4つも
レス返すなよｗ
>ここはzfsのメモリについて議論するためのスレじゃ無いですし、自分でzfsのスレ立てるべきです。
freenasがZFS採用してるんだから、ZFS話すのは当然だろ？
スレの2以降を読んでみろよｗ
ZFSに絡まない話は何一つしてないよｗ
お前らの頭はマジ狂ってるよ。 NASってSATAケーブルやSATAポート変えた場合に影響でますか？ 4月12日までのpringのアプリ新規登録キャンペーン、せこい奴ばっかだね。
招待コード使って新規登録してもらうだけで、自分にも500円入るのに謝礼しない奴ばっか。
俺は400円謝礼として送金するよ。
招待コード rguyen
登録は後でを選択してから、上記の招待コードを入力するだけ。
コード入力場所は幹事赤字応援キャンペーンから入力できるよ。
俺はマジで500円もいらんから必ず400円送金するよ。
だから招待コード使って新規登録してくれた貴方には計900円が入って即出金できるよ。
どうしても俺の500円を謝礼で全部欲しいと言う方は、pring内から連絡下さい。 まぁ少なくともL2ARCの使用はメモリ64GB以上てのは公式で書かれてるけどね
ただ絶対じゃなく推奨だけど
メモリ少ないのにL2ARC搭載すると逆に遅くなる場合があるので
L2ARCを検討する前にまずメモリ増やしてねて感じだったと思うが >>752
単に経験則でこうした方が良いよ、って書かれてるだけでしょ。
それに対して、海外のフォーラムでも「私の場合はでもそれは当てはまるのか？」
と言ったやり取りは出ている。で、「経験則で、と書いてあることに注意してね、
その人がそれを推奨してるなら、その人はその環境でテストしたんでしょう。
でもその時のパラメータは俺達には分からない。」
と、指摘されている。そりゃそーだ。150TBとかのDC運用の人と、家庭で10T
ソコソコのNAS運用が同じパラメータの訳は無い。大して気にするような話じゃない。 このスレには何故かそれを鵜呑みにしてる奴が大勢（？）いる。 昔SMB越しに雑にCrystalDiskMarkかけた時はL2ARC有りの方が結果悪かったな
週末暇あったらちゃんと計測してみっかな ここでせっかく持論を書くならば、
パフォーマンスチューニングの wiki でも
つくってくれまいか。
俺はその方が勉強になる。 >>755
L2ARCがちゃんと動いている検証なら、例えば8GBのメモリに16GBのSSD
付けて、9GBのデータを「2回」（キャッシュだから）コピーして計測するとか、
そういった事をやらないと意味ない様な気がするが…？ >>758
version history が9.0どまり？微妙に古くね？
>>739にある様に、ZFSつい最近結構進化していて、実際件の64GBメモリ推奨
もver 11では32GBに減らされている。※SSDも10倍
https://www.ixsystems.com/documentation/freenas/11.2/zfsprimer.html
As a general rule, L2ARC should not be added to a system with less than 32 GiB of RAM, and the size of an L2ARC should not exceed ten times the amount of RAM. In some cases, it may be more efficient to have two separate pools: one on SSDs for active data
やるなら最新版でチューニング紹介無いかな？ ZoLのドキュメントが最新だぞ
freeBSDもLinuxのZFSをベースに作ることになったから すみません。あまりに基本的な質問かもしれませんが、お願いします。
HDD 6台でRAID-Z2の運用をしている場合、
もし、「一台のHDDだけ、動作はしているんだけれども、返してくるデータがおかしくなっている」
という状態になった場合、読み出し時に修正されたり、エラーが返ってきたりとかどういう動作をするのでしょうか？
読み出し時にパリティを全部チェックして正しいデータを読み出してくれるのでしょうか？
それに関連した文書がどこかにあれば教えてください。お願いします。 >>761
通常はチェックサムに従って正常なデータに修正される
プールの情報を見るといつどれだけのサイズをどの程度の時間かかって修正したかの情報が表示される
zfsの挙動としてはアクセス時にチェックサムとの整合性を合わせる
このあたりから関連するリンクを探していけば望みの情報に行き着かないかな？
https://docs.oracle.com/cd/E19253-01/819-6260/gamno/index.html >>762
ご丁寧にありがとうございます。
勉強してきます。 xigmaNASでGPTラベル名をつけてGPTラベルでプール構成することはできますか？
FreeBSDではできるということだけど、そうなると全部シェルでやらないといけなくなります？ ■ このスレッドは過去ログ倉庫に格納されています
