ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × いつのまにかZoLとOpenZFSが統合されてた&永続的L2ARCが来るっぽい 2020年12月1日、ZoLベースとなるOpenZFS 2.0が無事にリリースされた ZFSのLinux向け実装であり今やZFS開発のメインストリームであるZFS on Linux (ZoL)が、いつの間にかOpenZFSと統合されていた。実際のところ、統合というよりはOpenZFSがZoLベースで仕切り直され、ZoLがOpenZFSに名前を変えたという感じのようだ。 経緯はともかく、既にZoLのGitHubはOpenZFSのリポジトリへとリダイレクトされるようになっている。で、2020年、すなわち今年にはZoL 0.8をベースとしたOpenZFS 2.0がLinuxとFreeBSD向けにリリース見込みとなっている。この辺のロードマップはOpenZFS Developer Summitでの発表資料(PDF)に詳しい。 また、そう遠くない未来に永続的L2ARC (Persistent L2ARC。界隈ではpL2ARCと表記されている)が取り込まれるようだ。 ZFSerにはご存じのとおり、L2ARCはSSDなどの高速ストレージを使ったZFSの読み込みキャッシュの仕組みである。必要な時に後から有効化できたり、不要になったらいつでも無効化できたりと、簡単便利な仕組みだが、システムの再起動でキャッシュ内容が失われてしまう欠点がある。正確には、キャッシュデータはストレージ上に残っているものの、メインメモリのキャッシュ管理データが消えてしまうため、現状のL2ARCは事実上の揮発性キャッシュとなっている。 pL2ARCでは、その名前のとおりシステムを再起動しても以前のキャッシュが維持されるようになる。ちなみに、L2ARCの管理データは無視するには大きすぎるサイズとなる。あまり巨大なL2ARCを作ると管理データがメモリを圧迫し、L2じゃない方のARCが減るという本末転倒な事態に陥るので注意が必要。 pL2ARCの構想自体は旧OpenZFSのロードマップにも存在していた。2015年にillumos向け実装の移植が試みられていたようだが、結局実現はしなかった。ところが最近になって、これまたZoLパワーでもって急速に開発が進められている。現時点でOpenZFS 2.0リリース予定には組み込まれていないものの、既にプルリクが作られており近々masterに取り込まれそうな勢いである。Linuxパワーしゅごい……。 参考サイト Persistent L2ARC by gamanakis · Pull Request #9582 · openzfs/zfs · GitHub NEX-3514 Implement persistent L2ARC · Issue #3744 · openzfs/zfs · GitHub Persistent L2ARC might be coming to ZFS on Linux | Ars Technica 記憶域のNTFSはアロケーションユニットサイズ大きめで作成する Windowsの記憶域プール上にNTFSの仮想ボリュームを作る時は、NTFSのアロケーションユニットサイズ(クラスタサイズ)をよーく考える事。思わぬところでNTFSの最大容量制限に引っかかることになる。 NTFSでは1ボリュームあたりのクラスタ数は2^64-1個が上限となっている。つまり、ボリュームの最大容量はクラスタサイズで決まる(最大容量=クラスタサイズ×最大クラスタ数)。アロケーションユニットサイズと最大容量の関係は下表となる。 クラスタサイズ 最大ボリュームサイズ 4KB 16TB 8KB 32TB 16KB 64TB 32KB 128TB 64KB 256TB (2020/12/01 追記) 家のWindows 10マシンで確認したところ、いつの間にかアロケーションユニットサイズとして128KB~2MBが追加されていた。Windows Serverでは2019で対応したっぽい。追加分は下表のとおり。 クラスタサイズ 最大ボリュームサイズ 128KB 512TB 256KB 1PB 512KB 2PB 1MB 4PB 2MB 8PB これだけ拡張されればNTFSもまだまだ行けるね! 2020-02-18現在、デフォルトクラスタサイズは昔から変わらず4KBのため、NTFSの1ボリューム≒1パーティションの最大サイズは16TBとなる。言うまでもないが、クラスタサイズを後から変更するのは無理。 一般的な使い方なら4KBでも十分だろうけど、容量拡張が容易な記憶域プールの場合、いとも簡単にこの最大ボリュームサイズ制限に引っかかってしまう。仮想ディスク上のNTFSボリュームを拡張すべく記憶域プールの容量を増やし、仮想ディスクを拡張し、いよいよNTFSパーティションを拡張だぜ!って段階で16TB制限に遭遇することとなり、マジ真顔状態となる。ありえねーよほんと…… 16TBのHDDがふつーに変えてしまう昨今、やろうと思えばその辺のマザボですら16TB×8本で128TBの記憶域プールが作れてしまう。そう考えると、記憶域プール上のNTFSのクラスタサイズは64KB、と脳死対応をしてしまっていいのかも。あるいはNTFSを捨ててReFSに行ってしまうか。アロケーションユニットサイズは、ボリュームにおけるデータの最小管理単位なので、無暗に大きくすると無駄が多く発生する可能性もあって悩ましいところ。 あー、10TBのデータをバックアップから復元するのめんどくせー。 FreeBSDのkern.random.harvest.maskについて FreeBSDのネットワークチューニングについて調べてると「random harvestを最適化せよ」という指示が随所で出てくる。ネットワークなのに乱数?と不思議に思って調べたメモ。ここで書くことは、全て一次ソースのrandom(4)とrandom_harvest(9)に書いてあり、FreeBSD 12.1-RELEASE時点での情報である。 まずはrandom harvestについて。 FreeBSDは乱数を返すスペシャルファイル/dev/randomを持つが、通常、その実態は擬似乱数生成器となっている。つまり数式で求められた確定的な乱数っぽい数値を返しているに過ぎず、乱数っぽさの維持にはエントロピーの質が重要となる。FreeBSDでは、エントロピーの収集のことをrandom harvestと呼んでいるようだ。良質なエントロピーを育み利用する、という感じなので“harvest”はなかなか的を射た呼び方だと思う。 そのエントロピー収穫先を制御するのがkern.random.harvest.maskカーネル変数というわけ。 値は収穫先ごとのビットフラグで、1ならエントロピー源として使う、0なら使わないことを意味する。10進数のマスク値を見ても良くわからないので、エイリアスであるmask_symbolicやmask_binを見た方がいいだろう。うちの環境では以下のとおりだった。 $ sysctl kern.random kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 00000010000000111111111 kern.random.harvest.mask: 66047 kern.random.random_sources: 'Intel Secure Key RNG' mask_binがmask値の2進数表現、mask_symbolicがmaskを更に読みやすくしたシステムで利用可能なエントロピー源の一覧で、[]で囲まれた収穫先は使われていないことを意味する。FreeBSD 12.1-RELEASE時点で、24個のエントロピー源が定義されているようだ(sys/sys/random.h)。 ご覧の通りNET_ETHERもエントロピー源として使われている。それがなぜネットワーク性能に影響するかというと、エントロピー収穫の際のロック競合が少なくない影響を及ぼしているとのことだ。とりわけ、10ギガビット以上の高速ネットワークではバカにならないそうで。なるほどねー。 参考サイト random(4) random_harvest(9) Tuning FreeBSD for routing and firewalling(PDF) メモリ16GBは人権の今、ZFSの重複排除(dedup)を解禁する (2020-12-15 追記) dedup有効状態で10ヵ月弱使ってみたけど、やっぱりまだ解禁しない方がよさげ。メモリ的には余裕だが、ファイル削除に時間がかかるようになったり微妙に怪しげな挙動をすることがある(何となくレコード毎に重複チェックが走り本当に削除するかどうかを決定しているような感じ。ファイルサイズと削除所用時間は比例する。要検証)。データの破損や消失は起きてないので、そういった意味での危険性はないが、有効にするなら何が起きても自己責任ってことで! ZFSは2010年頃のPool Version 21で重複排除機能(dedup)を備えたが、本機能の使用は長らく禁忌とされてきた。というのも、Chr〇meも真っ青のレベルでメモリを馬鹿食いするからだ。ZFSの他の機能同様、dedupも有効にした後の書き込みから機能するため、当初は問題なく動いてるように見える。が、徐々にメモリが使われて行き「なんか重いなぁ…」と気付いた時には既に遅し、メモリが枯渇しているのである。慌ててdedup=offにしても、既に重複排除された分は効き続けるため、メモリは減ったままというオマケ付き。dedup地獄から抜け出すには、メモリを増設するかスワップを大量に割り当て、既存の重複排除が解除されるのをひたすら耐えるしかない。 そんな訳でdedupの実用は難しかったのだけども、メモリ16GBは人権宣言から1年、フッ化水素騒動も何のその、メモリ価格は下落を続け個人でメモリ1TBも現実的となってきた昨今、そろそろdedupを解禁しても良いのではないか。 FreeBSD Mastery: ZFSによると、dedupはデータ1TBあたり概ね5GBのメモリを消費するそうだ。うちの自宅サーバはメモリ64GBでメインのプールは8TBなので、dedupを有効にしてもお釣りがくる計算だ。ならば人柱よろしくdedupっちゃおうじゃないの。ちなみに、同書にはdedupメモリ消費量のより詳しい見積もり方法が書いてある。気になる人は買って読んでください。 dedupを有効にするプールzhomeは以下のような感じ。8TBのHDDを2本(ada5とada6)のミラー構成としている。改めてみるとファイルシステム名のつけ方が酷いな…。 $ zpool status zhome pool: zhome state: ONLINE scan: scrub repaired 0 in 0 days 02:21:29 with 0 errors on Thu Oct 24 11:57:54 2019 config: NAME STATE READ WRITE CKSUM zhome ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada5p1 ONLINE 0 0 0 ada6p1 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 nvd0p3 ONLINE 0 0 0 nvd1p3 ONLINE 0 0 0 cache nvd0p7 ONLINE 0 0 0 errors: No known data errors $ zpool list zhome NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zhome 7.27T 1.22T 6.04T - - 2% 16% 1.00x ONLINE - $ zfs list -r zhome NAME USED AVAIL REFER MOUNTPOINT zhome 1.22T 5.81T 96K /zhome zhome/R 1.21T 5.81T 88K /zhome/R zhome/R/home 1.21T 5.81T 1.21T /usr/home zhome/ROOT 15.5G 5.81T 96K /zhome/ROOT zhome/ROOT/nextcloud 6.78G 5.81T 6.78G /mnt/nextcloud zhome/ROOT/vm 8.69G 5.81T 88K /zhome/ROOT/vm zhome/ROOT/vm/virtcurrency 8.69G 5.81T 8.69G /zhome/ROOT/vm/virtcurrency とりあえずホームディレクトリが置いてあるzhome/R/homeでdedupを有効にしてみる。 # zfs set dedup=skein zhome/R/home dedup=onではなくdedup=skeinなのは、チェックサムアルゴリズムとしてSkeinを使いたいから。 dedupは標準でSHA-256を使うようになっているが、manを見る限りSkeinはSHA-256/SHA-512より安全かつ高速で、更にプール固有のソルトを用いるためハッシュ衝突攻撃にも強いらしい。「sha512は何からの理由で高速なskeinが使えないシステムで使う」とも書いてあるので、基本はskeinで良さそう。 その後、別プールにあるISOイメージやらインストーラやらが詰まってる493GBのフォルダを、dedup有効のプールにコピーした結果が以下。 $ zpool list zhome NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zhome 7.27T 1.64T 5.62T - - 3% 22% 1.11x ONLINE - 重複排除率が1.11xってのは……たぶん2.00xならdedupで実使用量が半分になったって事だろうから、(重複排除できたサイズ)=(1-(1/DEDUP))*(元のサイズ) なので48GBほど排除できた感じっすかね? この時のメモリ使用量の変化は下図のとおり。 ARCサイズはloader.confでvfs.zfs.arc_max=“20G”として20GBに制限している。dedup前はARCを20GBフルに使ってるのに対し、dedup後は15GBになっていることから、dedup用のハッシュキャッシュはARCから確保されるっぽい? データ493GBでハッシュ5GBって冒頭の概算の2倍消費しとるやんけ!と思ったが、Skeinは512bitハッシュなので比率で考えたら見事に概算通りの結果となった。そう考えると、メモリ64GB程度ではdedupを使うにはまだ心許ない感じがするなぁ……(何というオチ)。ちなみに、将来dedupのメモリ消費量が削減される可能性があるっぽい。 まぁ、せっかくdedup有効にしてみたんだし、しばらく運用してみよう。NVMeなSSDも載ってるので、最悪そっちに大容量スワップ作れば何とかなるだろう。 (2020-01-06 追記) dedup有効後、6日ほど経ったのでtopを見てみたら、ARCが20GBに戻ってた…。ARCからハッシュキャッシュから取られる訳ではなさそう?ちゃんと調べてみないと分かりませんな……。 last pid: 26323; load averages: 0.21, 0.20, 0.17 up 71+13:01:17 22:29:52 51 processes: 1 running, 50 sleeping CPU: 0.8% user, 0.0% nice, 0.3% system, 0.0% interrupt, 98.9% idle Mem: 295M Active, 1465M Inact, 25G Wired, 35G Free ARC: 20G Total, 11G MFU, 6802M MRU, 1530K Anon, 369M Header, 1446M Other 17G Compressed, 24G Uncompressed, 1.43:1 Ratio Swap: 参考サイト zfs(8) OpenZFS、重複排除機能が改善される可能性あり | マイナビニュース 我が国では人権はいくらでも蹂躙して構わないことになっているので「メモリ16GBは人権」といういい方はNG、という説 - Togetter Nextcloudのプレビューの文字化けを直す Web版Nextcloudで表示されるテキストファイルのプレビュー画像が文字化けしてたので直してみた。 やることは、プレビュー生成で使っているフォントをNotoSansCJKに変更するだけ。手順は↓こんな感じ。 https://github.com/minoryorg/Noto-Sans-CJK-JP/tree/master/fonts から NotoSansCJKjp-Regular.ttf をダウンロード DLしたフォントを Nextcloudのインストール先/core/fonts に入れる 上記フォルダでNotoSansCJKjp-Regular.ttfをNotoSans-Regular.ttf (Nunito-Regular.ttf)にリネームする(シンボリックリンクでも可) Nextcloudの標準フォントに、日本語のグリフが含まれていないのが原因のようだ。当初は文字コード周りかと思ってたが、プレビューをよく見ると“豆腐”になっていることが分かる。 プレビューの生成はファイルが変わった時に行われるようなので、てきとーにファイルを編集すれば正常な表示になるはず。 もう少し詳しく解説すると、テキストファイルのプレビューの生成はlib/private/Preview/TXT.phpで行われており、80行目あたりでNotoSans-Regularが指定されている→GitHub/master Notoなのに何で文字化け…?と思ったのだが、同梱のNotoには日本語のグリフが含まれていないようだ。ついでに、Notoが使われるようになったのはごく最近で、以前はNunitoが使われていたようだ→GitHub/Move font from Nunito to Noto Sans というわけで、使ってるNextcloudのバージョンに応じて、NotoSans-Regular.ttfもしくはNunito-Regular.ttfを日本語グリフを含むフォントに差し替えればおkというわけ。 < Newer Posts 1 2 ... 13 14 15 16 17 18 19 ... 82 83 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo