FC980Cはいいぞ、Realforce好きなら買いたまえｍ9っ｀ω´) ﾋﾞｼｯ!!

（製品仕様を意識してか静電容量の関係式があしらわれてるけど、ふつーにメーカー名か型番の方がカッコイイと思う…）

LEOPOLDのキーボード「FC980C/EWWP」(AECX01、45gモデル)を買った。テンキーレスと同等のサイズにテンキーを詰め込んだ変則配列のキーボードで、今や「96%キーボード」と呼ばれるジャンルが確立されているっぽい。

色はホワイトを選択。公式はホワイトと言ってるけど、全く白ではない。Realforceのアイボリーよりも黄色い。クリーム色というか、軽微なヤニ色ないしレトロブライト色というか……灰色のキートップと相まったレトロ調で僕は好きですよ。

FC980CはTopreスイッチ採用ってことで、要は96%キーボード版Realforceとも言える製品である。筐体はR2ベースっぽいが、キー入れ替え用のDIPスイッチがあるので中身は初代なのかしら？入れ替え用CtrlとCaps LockキーキャップはR2用のものが使えた。

FC980の配列や幅と各種Realforceの比較は↓の写真のとおり。上からFC980C、Realforce 87UW-S、Realforce R2 TKL、Realforce R2である。

（CtrlとCaps Lock、DeleteとNum Lockは本来の配置とは入れ替わっているので注意。）

よくよく考えてみると、テンキーレス版RealforceはカーソルキーやらDel/Insertなどのキーやらで3列分の幅があるため、そこに1列分追加してやれば比較的無理なくテンキーが入っちゃうのよね。

FC980もそんな感じで、アプリケーションキーを取り除き、右Shift、右Ctrl、テンキー0の幅を縮め、使用頻度の低いキーをFnとのコンビネーションにすることで巧いこと納めている。これが中々よく考えられた配列で、普段使いではフルサイズのキーボードと遜色なく使えるのが素晴らしい。

右Shiftが短くなったのはともかく、右Ctrlは1文字分となり位置も変わってしまっている。むしろFnキーと逆の方がいいんじゃないの、と当初は思ったが意外や意外、薬指で無理なく押せる。むしろ、一般的な位置の右Ctrlを小指で押すよりも手首への負担が少ないとさえ感じる。これ考えた人デキる…！

個人的にはNum LockとDeleteキーの位置は逆であってほしかった。Deleteが最上段ってのはちょっと遠い。Num Lockなんて、そうそう切り替えるものでもないだろうし……それこそ右上かコンビネーションキーで良かったんじゃないかと思う。慣れの問題のような気もするが、やはり小指で押すには遠かったのでKeyboard Quantizerでキーマップを入れ替え、キーキャップも入れ替えて対応した。

キーの荷重は恐らくALL 45gと思われる。取説には45g(±15g)の記載があったり、ネット上の情報では変荷重とされていたりで正直よくわからん所ではあるが、AとSの感触の違いが分からないこと、何よりESCキーが重くない（変荷重なら55gで明らかに重い）ことから全45gだろう。

打鍵感はRealforceそのものだけど、R2のそれではない。Realforce 86Uに一番近い……ような気がする。手放し済みで直接比較ができないのだが、少し硬めで戻りが素早く、底打ちをキーボード全体でしっかり受け止めているような安定感抜群の打ち心地は、記憶の中の86Uとそっくりだ。

Realforceって、基本仕様が同じハズのモデルでも、何故かバリエーション（色違いとか）で打ち心地が全然違うのよね。86Uはいわゆる“スコスコ”だが、87UBは若干粘つきと全体的に響く感じで“スチャスキョ”、87UW-Sは86U準拠で静音機構分の粘りと静音化で“スｺスｺ”、R2は全体的にキーの揺れと鳴りが大きく軽めの“スキャスキャ”という具合で（※感じ方には個人差があります。）

ともかくだ、初代Realforceの打鍵感が好きな自分としては、FC980Cの打ち心地は最高ってこと！

FC980Cはいいぞ、Realforce好きなら買いたまえｍ9っ｀ω´) ﾋﾞｼｯ!! （2回目

• LEOPOLD LEOPOLD FC980C White (45g)
• LEOPOLD FC980C シリーズ（英語ASCII配列） - 株式会社アーキサイト
• Keyboard Quantizer

自鯖のNextcloudを23に更新し、occ db:add-missing-indicesを実行しようとしたらOCP\HintExceptionなる例外が発生した。

$ sudo -u www php /path/to/occ db:add-missing-indices
An unhandled exception has been thrown:
OCP\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

occ単発で動かしても同様で、根本的に何かが悪いっぽい。

助けて～ぐーぐるせんせーってことで、ググったら公式にそれっぽいissueが上がっていた。

いわく、apc.enable_cli=1を付けて実行する必要があるとのこと。APCuを明示的に有効化する必要がある雰囲気？とりあえず言われたとおりにやってみる。

$ sudo -u www php --define apc.enable_cli=1 /path/to/nextcloud/occ db:add-missing-indices
Check indices of the share table.
（中略）
oc_properties table updated successfully.

無事動いた。

改めてNextcloudのマニュアルを見てみると、Memory cachingのAPCuのところにちゃんと書いてあった。

デフォルトではCLIからの実行時はAPCuが無効化されているそうで、明示的に有効化しなきゃならんとのこと。NextcloudのCronジョブにも影響するので、そっちの方も個別に対応するか、php.iniに先のapc.enable_cli=1を追加しておく必要がある。

なるほどなー、だから管理画面に「長期間バックグラウンドジョブが動いていないようです」メッセージが表示されてたのかー。

• 21.0.3 OC\HintException: Memcache \OC\Memcache\APCu not available · Issue #27781 · nextcloud/server · GitHub
• Memory caching — Nextcloud latest Administration Manual latest documentation

プールのメタデータを丸っと引き受けるというZFSのSpecial vdevの特性から、対応する物理デバイスの故障などでSpecial vdevが死ぬと、プールそのものが使えなくなりそうってのは容易に想像ができる。

実際どうなるか仮想マシンベースで確認してみると、やはり使えなくなった。それもzpool listの結果にプール自体が出てこなくなるという、割と重篤な扱い。プール名を指定 or プール探索でインポートしようとすると、以下のようになってインポートできない。

# zpool import -a -N
cannot import 'ztest': I/O error
        Destroy and re-create the pool from
        a backup source.

存在しないプールのインポートではcannot import 'znotexists': no such pool availableって感じなので、明らかに扱いが違う。

Special vdevが消失したプールの復旧は基本的に無理っぽい感じ。

一応man zpool-importを見てみると、（いつの間にか）プール回復に関するオプション-F, -X, -Tが追加されていた。それぞれの効果を抄訳してみた。

-F < -X < -Tの順で強力（危険）になる雰囲気。で、それぞれを指定して、先のSpecial vdevが無くなったプールのインポートを試みたのが以下。

# zpool import -F ztest
cannot import 'ztest': I/O error
        Destroy and re-create the pool from
        a backup source.

# zpool import -FX ztest
cannot import 'ztest': one or more devices is currently unavailable

# zpool import -T ztest
invalid txg value
usage:
        import [-d dir] [-D]
        import [-o mntopts] [-o property=value] ...
            [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]] -a
        import [-o mntopts] [-o property=value] ...
            [-d dir | -c cachefile] [-D] [-l] [-f] [-m] [-N] [-R root] [-F [-n]]
            [--rewind-to-checkpoint] <pool | id> [newpool]

-Tはtxgを指定してやらないとダメな予感。usageにもmanにもそれらしいことは書いてないんだけど…実際にどんな値を指定したらいいのか皆目見当もつかない。

その後、Special vdev用の仮想ディスクを戻してみると、問題なくプールのインポートができた。ただし自動インポートはされず、手動で行う必要があるようだ。（上記の-Fとかでプールを操作したためかもしれないが未確認。）scrubで健全性に問題がないことも確認。

そんなわけでSpecial vdevの冗長性には十分気を付ける必要がありそうだ。

階層化ストレージのZFS版ともいえるSpecial vdevとSpecial Allocation Classについて、1年程前に当サイトでも解説した。いつか試そうと思いつつ延び延びになっていたが、いよいよ導入の機運が高まってきたので簡単にテストした。

まずはコマンドの確認から。以下、da0p1をノーマルvdev（プール本体のストレージ）、da6p1をスペシャルvdevとする。

スペシャルvdev付きプールを作る。vdevタイプとしてspecialを指定し、その後にスペシャルvdevに割り当てるデバイスを指定する。

# zpool create -O atime=off ztest da0p1 special da6p1
$ zpool status ztest
  pool: ztest
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        ztest       ONLINE       0     0     0
          da0p1     ONLINE       0     0     0
        special
          da6p1     ONLINE       0     0     0

既存のプールにスペシャルvdevを追加する場合はzpool addで同様に指定する。

# zpool add ztest special da6p1

スペシャルvdevの削除。これはL2ARCやslogの削除なんかと一緒。

# sudo zpool remove ztest da6p1

ただし、remove後にスペシャルvdevからノーマルvdevへ、データの退避が行われる。

$ zpool status ztest
  pool: ztest
 state: ONLINE
remove: Evacuation of /dev/da6p1 in progress since Wed Feb 23 16:50:17 2022
    2.77G copied out of 13.5G at 142M/s, 20.54% done, 0h1m to go
config:

        NAME        STATE     READ WRITE CKSUM
        ztest       ONLINE       0     0     0
          da0p1     ONLINE       0     0     0
        special
          da6p1     ONLINE       0     0     0

$ zpool iostat -v ztest
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
ztest       14.4G  9.13T     16     68   215M   220M
  da0p1      932M  9.09T      0     68      0   220M
special         -      -      -      -      -      -
  da6p1     13.5G  36.0G     16      0   215M      0
----------  -----  -----  -----  -----  -----  -----

退避が完了するとプールからデバイスが除去される。

$ zpool status ztest
  pool: ztest
 state: ONLINE
remove: Removal of vdev 1 copied 13.5G in 0h1m, completed on Wed Feb 23 16:51:31 2022
    27.4K memory used for removed device mappings
config:

        NAME          STATE     READ WRITE CKSUM
        ztest         ONLINE       0     0     0
          da0p1       ONLINE       0     0     0

スペシャルvdevは標準でメタデータのみを格納する設定となっている。小ブロックデータの格納を有効にするには、ファイルシステム毎のプロパティspecial_small_blocksを0以外の2の冪数に設定する。

# zfs set special_small_blocks=64k ztest/R/pictures
$ zfs get -r special_small_blocks ztest
NAME              PROPERTY              VALUE                 SOURCE
ztest             special_small_blocks  0                     default
ztest/R           special_small_blocks  0                     default
ztest/R/pictures  special_small_blocks  64K                   local

スペシャルvdevが使われてるかどうかはzpool iostat -vで確認できる。書き込み中に見てみると、しっかりスペシャルvdevも使われていることがわかる。

              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
ztest       11.7G  9.13T      0  1.36K      0   213M
  da0p1     11.4G  9.08T      0    215      0   207M
special         -      -      -      -      -      -
  da6p1      277M  49.2G      0  1.15K      0  6.22M
----------  -----  -----  -----  -----  -----  -----

スペシャルvdevの有無、special_small_blocksのサイズ、レコードサイズの違いで簡単にテストを行う。

• テストデータ
  • 72208ファイル、10.3GiB（平均ファイルサイズ：150KiB）
  • Special vdevの効果が出やすいであろう、大量の小サイズの画像ファイル群
• テストマシン
  • OS: FreeBSD 13.0-RELEASE-p6 on Proxmox VE 7.1
  • CPU: 4 vCPU (Xeon E5-2680v4. オーバーコミットなし)
  • RAM: 32GB
  • HDD:
    • コピー元: 単体 (仮想ディスク50GB/実態はU.2 SSD)
    • コピー先: 単体 (10TB 7200RPM SATA HDD×1)

コピー先のプールのスペシャルvdevの有無によって、以下の項目を測定する。

• コピー元→コピー先へのファイルコピー所要時間（rsync -aX src dst/）
• コピー先でファイルの全走査にかかる時間（find dst > /dev/null）
• コピー先でファイルの全読込にかかる時間（find dst -print0 | xargs -0 cat）

ARCの影響を避けるため、プールは都度作成し、rsync後はマシンを再起動する。その後、ファイル走査→全読込の順で実行する。

仮想マシン上での実行のため、結果にはノイズが多く含まれていることに注意。

※special_small_blocks=4k～32kは後から測定したため、スペシャルvdevの容量のみ。グラフには加えていない。1MBずつ増えてて本当かよ？と思ったが、再度試しても同じだったので間違ってるわけではなさそう。

スペシャルvdevの有無でファイルコピー（書き込み。赤線）時間に有意な差は見られなかった。ただし、これはコピー元の読み込みで律速してる可能性が否定できない。コピー先の書き込み状況をiostatを眺めてみると間欠動作となっていた。

ファイルの全走査はスペシャルvdevがあると劇的に高速化されるようだ。iostatを見てみると、スペシャルvdevで読み込み処理が走っており、SSD上のメタデータが使わているものと思われる。期待通りの挙動ですな。

ファイルの全読込も、スペシャルvdevに保存されているデータ量に応じて短縮されており、こちらも想定通り。recsize=128kでspecial_small_blocks=128kとすると、全データがスペシャルvdevに保存されるというのも期待通りの結果だった（special_small_blocksで指定されたサイズ以下のレコードのデータがスペシャルvdevに保存される仕様。）iostatを見てみると、見事に全てスペシャルvdevに書き込まれていることが分かる。

              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
ztest       13.2G  9.13T      0  2.21K      0   236M
  da0p1         0  9.09T      0      3      0  15.2K
special         -      -      -      -      -      -
  da6p1     13.2G  36.3G      0  2.20K      0   235M
----------  -----  -----  -----  -----  -----  -----

少し意外だったのは、special_small_blocksが0、すなわちメタデータのみをスペシャルvdevに保存した場合でも、ファイル読込性能が向上したという点。今回は小さな大量のファイルが対象だったため、読込み処理におけるメタデータの処理割合が多かったのが要因だろう。

また、スペシャルvdevと直接は関係ないが、レコードサイズでメタデータサイズが大きく変化するというのは新たな発見だった。全くの推測だが、おそらくレコードごとに生成されるチェックサムの総量が影響しているのだろう。10.3GiBを128kiBレコードで割ると約84000レコードで、それぞれにfletcher4（4バイト）のチェックサムが付くと、合計330MiBとなる。同様に1MiBレコードでは41MiBとなり、これらはメタデータのみをスペシャルvdevに保存した際の容量とおおむね一致する。

さらに1MiBレコードではファイル読込が明らかに速くなっており、圧縮率の観点等も考慮すると積極的に128KiB以上のレコードサイズを使っていくのが良さそう。

special_small_blocksの設定をどうするかは悩ましいところ。扱うデータの種類やワークフローはもとより、TXG関連の設定やその時々の負荷量などで、書き込みがスペシャルvdev行きとなるかどうかが変わってくると思われ、見積もるのが難しい。今回は64k/128kの2パターンしか見なかったが、運用においては、より小さな設定値も検討に値するだろう。むしろ、とりあえず4kあたりから始めて様子を見るのがいいのかもしれない。 → 気になったので4k～32kを追試したけど、32k以下は殆ど効果がなさそう。スペシャルvdevの運用としては、容量が見積もりやすいメタデータのみとするか、ある程度余裕を持たせて64kで始めるの2択になるかも。

メタデータだけでもスペシャルvdevの効果は期待できそうなので、SSDに余裕があるならL2ARCよりも優先的に割り当てて良さそうに思う。

ZFSerの皆様におかれましては、OpenZFS 2.0で圧縮アルゴリズムにZStandardが追加されたのは周知の事実だろう。compressionの値としてzstd-Nとzstd-fast-Nが指定できるようになったが、設定値と圧縮率の関係性は以下のとおり。

zstdとzstd-fastで数値の関係性が逆転しているように見えるが（というか設定値上はそういう風にしか見えないのだが）、zstd-fastの方は負数を表しており、-1000が最小でスーパー速度重視ということなので一貫性が取れている。

ZStandardはLZ4より圧縮率が高く、それに応じて処理負荷も若干高いとされている。実際のところどんなものか、簡易的にテストした。

個人的にアーカイブ用途に使いたいので、圧縮率重視ってことでzstdのみが対象。だいぶてきとーな実験なので、あくまで傾向を掴むもの程度で見て欲しい。

ZFSの主要開発者の1人、Allan Judeによる真っ当なベンチマークも参照されたし。

テスト環境は以下のとおり。

• テストデータ
  • 12675ファイル、503GiB（平均ファイルサイズ：40.6MiB）
  • OS・アプリのISOイメージ、zip、インストーラexe、Macのdmg、appバンドルなど圧縮が効きにくいデータが多数
• テストマシン
  • OS: FreeBSD 13.0-RELEASE-p6 on Proxmox VE 7.1
  • CPU: 4 vCPU (Xeon E5-2680v4. オーバーコミットなし)
  • RAM: 64GB
  • HDD:
    • コピー元: RAID-Z2 (16TB 7200RPM SATA HDD×5)
    • コピー先: 単体 (10TB 7200RPM SATA HDD×1)

テストデータをコピー元のRAID-Z2プールから、テスト用のコピー先プールにrsyncでコピーする。cpじゃなくてrsyncなのは、終了時に転送速度を表示してくれて便利だからってだけで、他意はない。

圧縮アルゴリズム別のファイルシステムを作ってはコピーしての繰り返しで、途中プールの作り直しやファイルシステム削除はしてないので、HDDの外周/内周の転送速度差がテストに影響していることに注意。

加えて、仮想マシン上での実行だったり、テスト中もファイルサーバとして普通にアクセスしたり（といっても負荷をかけないよう自粛はしたけど）と、結果には様々なノイズが混入している点にも注意。

各圧縮方法ごとの圧縮後容量、圧縮率（無圧縮時を100%とした時の割合）、転送速度を下表にまとめる。

パターン1～3実行後、一応、HDDの内外周差を気にしてパターン1,2のデータは削除している。

パターン9が基準値。無圧縮で最内周に書き込んでいるので、これより遅いかどうかで、圧縮処理がボトルネックになっているかの目安になるかなと。書き込み先がHDD 1台のプールなので、そこで律速されてる感があるけど、まぁ実際の使われ方に近い環境ってことで大目に見てください。

グラフで表したのが下図。

まず言えることはzstd-3のバランスの良さ。LZ4と遜色ない速度にもかかわらず、圧縮率は有意に高い。さすが、compress=zstdとした時に使われるレベルだけある。gzip-9より縮むのに大分速いってのは特筆すべき。

圧縮率最重視のzstd-19が当然ながら最も縮むが、速度が大分厳しい感じ。少なくとも今回のテストデータでは、処理時間に見合うだけの効果が得られているとは言い難い。仮に最新CPUで速度が10倍になったとしても、250MB/s程度でボトルネックとなる可能性が高く使いどころが難しそう。費用対効果が高いのはzstd-7、状況によってはzstd-15もなくはないかな。

ついでに、圧縮はrecordsizeが大きいほど効果的とされているので、その影響も軽く測定。

LZ4とZStandardのそれぞれで、レコードサイズを512kから1Mに変更した時の圧縮後容量の差分を求めたのが下表。

なぜかLZ4のレコードサイズ1MBの時は圧縮率が下がってるけど、概ねレコードサイズが大きくなるほど圧縮率も向上するようだ。割合で見ると微々たるものだが、レコードサイズを変えるだけで恩恵が得られるのはありがたい。実のところ、レコードサイズを大きくすると実データに占めるメタデータ割合（ハッシュの量）が減り、プール容量的にはこちらの影響の方が大きかったりする（参考：ZFSのSpecial vdevを試してみる）

とりあえず、互換性を気にしなくていい環境では、lz4の代わりに積極的にzstdを使っていくのが良さそう。可能な限りrecordsizeも大きくしていこう（ただし、FreeBSDはレコードサイズが128k超のファイルシステムからブート出来ない点には注意が必要。）