このページの翻訳:
ソースの表示
最近の変更サイトマップ



いつのまにかZoLとOpenZFSが統合されてた&永続的L2ARCが来るっぽい

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)が取り込まれるようだ。

ZFSerにはご存じのとおり、L2ARCはSSDなどの高速ストレージを使ったZFSの読み込みキャッシュの仕組みである。後から必要な時に有効化できる簡単便利な仕組みだけど、システムの再起動でキャッシュ内容が失われてしまう欠点がある。より正確には、ストレージ上にはキャッシュデータが残っているものの、メモリのキャッシュ管理データが消えてしまうため、現状のL2ARCは事実上の揮発性キャッシュとなっている。

永続的L2ARCでは、その名前のとおりシステムが再起動しても以前のキャッシュが維持されるようになる。ちなみに、L2ARCの管理データは無視するには大きいサイズなので、あまり巨大なL2ARCを作るとメモリを圧迫しL2じゃない方のARCが減るという本末転倒な事態に陥るので注意が必要。

機能自体はOpenZFSのロードマップにも以前から記載があり、2015年にillumos向け実装の移植が試みられていたようだが、結局実現はしなかった。ところが最近になって、これまたZoLパワーでもって急速に開発が進められている。現時点でOpenZFS 2.0リリース予定には組み込まれていないものの、既にプルリクが作られており近々masterに取り込まれそうな勢いである。Linuxパワーしゅごい……。

参考サイト

メモリ16GBは人権の今、ZFSの重複排除(dedup)を解禁する

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.confvfs.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 on LinuxにRAID-Z Expansionのパッチが登場してた

表題の通り、ZoLにRAID-Z Expansionのパッチがコミットされていた→[WIP] raidz expansion, alpha preview 1 by ahrens · Pull Request #8853 · zfsonlinux/zfs · GitHub

まだα版ながらRAID-Z Expansionしたプールのimport/export、expansionのバックグランド実行等、基本的には動いているものの、不具合が発生した時はデータ消失の危険や、ディスクフォーマットは最終リリースとは異なるためテスト用とのこと。試される方は自己責任でオナシャス。



FreeBSDのZFS実装がZFS on Linuxベースに変更されるらしい

昨年末の話題ではあるけど、将来的にFreeBSDのZFSシステムがZFS on Linuxベースに変更されるらしい。メーリングリストを読む限り、Delphix社がZFS開発の軸をZFS on Linux(以下ZoLと表記)に移したことが発端となっているようだ。

これまで、OpenZFSの盟主たるDelphix社1)は、illumosからフォークした自社のDelphix OS用にZFSを改良し、それがOpenZFSに取り込まれてきた。現在のFreeBSDのZFS実装はillumosのコードがベースとなっており、FreeBSD用に多数のifdefを加えたものだそうだ。illumosという共通の祖先を持っていたからこそ、Delphixの改良がFreeBSDに取り込めてきたというわけだ。

ところが、前述の通りDelphixがZoLに移行したことで、illumosベースのZFS実装の改修が止まってしまった。現状、ZoLで行われた修正のillumosへのバックポートは全く行われていないそうである。ZoLの主要開発者であるBrian Behlendorfが、ZoLへのFreeBSD直接サポートの追加を薦めてくれたこともあり、ひとまずZoLをベースとしたZFS on FreeBSDプロジェクト、通称ZoFが立ち上がったという経緯のようだ。将来的にはZoLとZoFで1つのコードベースを共有するかもしれないとのこと。

ZoFの実装とテストはiX Systemsが主体となって行われており、既に殆ど問題なく動いているようだ。illumosの実装─界隈ではLegacy ZFSと呼ばれている─と比較してパフォーマンスも向上している模様。2019年3月1日にsysutils/zolとしてportsツリーに取り込まれ、2019年6月10日にはsysutils/openzfsへと名称変更されている。12.0-RELEASEのportsツリーにも取り込まれていることから、完成度の高さが伺える。FreeBSD 13の前にはillumosベースのZFSソースコードは削除されるだろうとのこと。

参考サイト

1)
自分が勝手にそう思ってるだけ

FreeBSDのZFSでミラープールにUSB接続のHDDを追加する

FreeBSD 12.0-RELEASEのZFSのミラープールにUSB接続のHDDをアタッチしてみた。USB接続だろうと何だろうと、いつもの手順でzpool attachすれば行けるはずだけど、実のところ今までやったことが無かった。/usr/homeを置いてるHDDが手狭になってきたため、交換ついでに試してみた記録。

まずは対象のミラープール(zhome)の確認。

$ zpool status zhome
  pool: zhome
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: resilvered 0 in 0 days 00:12:00 with 0 errors on Thu Nov 22 00:25:49 2018
config:

        NAME        STATE     READ WRITE CKSUM
        zhome       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada7p1  ONLINE       0     0     0
            ada8p1  ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            ada5p4  ONLINE       0     0     0
            ada6p4  ONLINE       0     0     0
        cache
          ada5p8    ONLINE       0     0     0

ada7p1とada8p1でミラー構成になっていることが分かる。

お次にcamcontrolで対象のHDDを確認。

# camcontrol devlist
<TOSHIBA MQ03ABB300 JP050U>        at scbus9 target 0 lun 0 (ada7,pass8)
<WD Elements 25A3 1021>            at scbus13 target 0 lun 0 (pass11,da0)
<WD Elements 25A3 1021>            at scbus14 target 0 lun 0 (pass12,da1)

必要なHDDのみ抜粋したため番号が飛んでいるが、ada7がプールを構成する2.5インチHDDの1つで、da0/da1がプールに追加するUSB接続の8TB HDDである。

da0/da1にパーティションを作る。自分はディスク全体ではなくパーティションでZFSを構成する派なのである。

8TBのHDDを用意したので、gpartでてきとーにda0のパーティションを切り、da1にそのままコピーする。

# gpart create -s gpt da0
# gpart add > gpart add -a 4k -t freebsd-zfs -s 15620000000 da0
da0p1 added
$ gpart show da0
=>         40  15627986864  da0  GPT  (7.3T)
           40  15620000000    1  freebsd-zfs  (7.3T)
  15620000040      7986864       - free -  (3.8G)

# gpart backup da0 | gpart restore da1
$ gpart show da1
=>         40  15627986864  da1  GPT  (7.3T)
           40  15620000000    1  freebsd-zfs  (7.3T)
  15620000040      7986864       - free -  (3.8G)

そして、いつも通りzpool attachする。コマンドが返ってくるまで結構時間が掛かって不安になるけど、強い心で待つ。

# zpool attach zhome ada7p1 da0p1
# zpool attach zhome ada7p1 da1p1

あとはプールのresilveringが終わるのを待つだけ、何だけれども、今回初めての現象に遭遇した。

デバイスをアタッチ後、zpool iostatで読み書きの状況を見ていたら、どういうわけか2MB/s程度の速度しか出ていない。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome       2.26T   474G    637      0  2.49M      0
  mirror    2.26T   474G    637      0  2.49M      0
    ada7p1      -      -    288      0  1.31M      0
    ada8p1      -      -    273      0  1.19M      0
    da0p1       -      -      0      0      0      0
    da1p1       -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror     388K  1.98G      0      0      0      0
    ada5p4      -      -      0      0      0      0
    ada6p4      -      -      0      0      0      0
cache           -      -      -      -      -      -
  ada5p8    10.6G   139G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

ミラーの片割れを物理的に取り外し、新しいHDDを取り付けてzpool replaceするいつもの方法、すなわちワザとプールをデグレさせて新しいHDDでミラーを復旧させる良い子のみんなは真似しちゃダメな方法だと直ぐにresilveringが走っていたのだけど…。

暫く観察してたところ、どうやらresilveringの前にプールの全走査?をしているっぽい?

$ zpool status zhome
  pool: zhome
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sun Jul 14 08:38:19 2019
        355G scanned at 1.08G/s, 1.25M issued at 3.89K/s, 2.26T total ★←ここ
        0 resilvered, 0.00% done, no estimated completion time
config:

        NAME        STATE     READ WRITE CKSUM
        zhome       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada7p1  ONLINE       0     0     0
(略)

上記ログを見て分かる通り、1.08G/sという2.5インチHDDにはありえない速さでスキャンが行われており、実際の読み込み速度と合わせて考えると何らかのメタデータを読んでる?

とりあえず「355G scanned at 1.08G/s」の部分がプールの容量に達した後、データの同期が開始されるようだ。一度始まってしまえば順当に100MB/s超の速度が出るのでしばらく待つ。

$ zpool status zhome
  pool: zhome
 state: ONLINE
  scan: resilvered 4.51T in 0 days 07:07:33 with 0 errors on Sun Jul 14 15:45:52 2019
config:

        NAME        STATE     READ WRITE CKSUM
        zhome       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada7p1  ONLINE       0     0     0
            ada8p1  ONLINE       0     0     0
            da0p1   ONLINE       0     0     0
            da1p1   ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            ada5p4  ONLINE       0     0     0
            ada6p4  ONLINE       0     0     0
        cache
          ada5p8    ONLINE       0     0     0

errors: No known data errors

終わってみれば94MB/s程度でresilveringが行われた事になるので、いつも通りの速度だったと言える。

というわけで、SATAとUSBのHDDを混在させても問題なくZFSミラー構成が取れるという事が分かった。まぁ、当然ですけど。

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0