中華製のPCケースZZAW C2を買った。フルアルミ製でMicroATX適合の超小型ケースである。

ドライブベイやUSBポート等を完全に廃し電源ボタンのみ搭載という超割り切り仕様とする一方、多少の制約はあるものの、その辺のMini-ITX用ケース程度の大きさで、ATX電源、フルサイズのビデオカード、PCIeスロット4本対応という、刺さる人には刺さりまくりな仕様となっている。

公式サイトはアリエクの販売ページだと思う。少なくとも、ここが一番詳しくてわかりやすい。とか言いつつ、送料を考慮すると一番安かったAmazonでお買い上げ。

中国からの発送で業者はYunExpress、国内配達は佐川だった。7/4に注文し7/12に到着、所要日数9日ってことで、比較的早い方かな。詳細な追跡情報は下表な感じ。関空経由は初めてかも。

製品箱に伝票が直張り状態だったけど、箱の角が少し潰れてるくらいで破損・汚れはなく届いた。

もちろん、中身は無事。

OpenZFS 2.1.4時点で、冗長性レベルを問わずRAID-Zプールに追加したスペシャルvdevを削除することは出来ないようだ。恐らく、トップレベルvdev削除の制限に起因する仕様と思われる。

次のようなRAID-Z1とスペシャルvdevから成るプールがあるとする。

# zpool status ztank
  pool: ztank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        zdata       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
        special
          mirror-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0

errors: No known data errors

ここで、スペシャルvdevを削除しようとzpool removeすると、次のようにエラーとなる。

# zpool remove ztank mirror-1
cannot remove mirror-1: invalid config; all top-level vdevs must have the same sector size and not be raidz.

トップレベルvdevのmirror-1を一気に削除するのがマズいのかと思い、次のように構成メンバを個別に削除してってもダメ。

# zpool detach ztank da5
# zpool remove ztank da4
cannot remove .....

なお、RAIDZ以外の構成なら特に制限なく削除可能で、同じトップレベルvdevであるslogやL2ARCの場合は、RAIDZでも（以前から）削除可能である。

家鯖でスペシャルvdevを本格運用すべく色々準備してたけど、削除できないのはちょっと厳しいなぁ…VMであらかじめ実験しといて良かったぜ……slog/L2ARCは削除できるんだから、将来的にできるようになるのかなぁ………スペシャルvdevの場合、明示的に本体プールの方にデータを書き戻す必要があって難しいのかなぁ…………

当面はpL2ARCを使うとするかー。

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の冗長性には十分気を付ける必要がありそうだ。