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超のファイルシステムからブート出来ない点には注意が必要。）

2021年末、Amazon.comでWD 16TB Elements Desktop (WDBWLG0160HBK-NESN)が289.99ドルになっていたので、5台購入した。12/23に注文し1/14に到着。クリスマスと年末年始（とコロナ？）のためか、いつもよりは到着まで時間を要した。一緒に買った物、輸入デポジットの返金を差っ引いて約1600ドル、クレカ明細を見たら1ドル117.163円とのことで合計187460円、1台あたり37500円となった。想定よりだいぶ高くついたな……円安が憎い……

当然(？)、外付けUSB HDDとして真っ当に使う気はさらさらないので、全領域ゼロフィルで動作確認が済んだところでご開帳～。なお、16TBを埋めるのに丸1日かかり、平均転送速度は180MB/s程となった。

中身はWD160EDGZ (WD160EDGZ-11B2DA0)だった。PC好きの備忘録さんの記事によれば、2021年初頭はWD160EDFZだったようなので、2021年のどこかでFからGに変わったのだろう。うちの個体は2021/7/18製造っぽい。製造から出荷まで結構時間がかかってるような感じがするけど、こんなもの？

HDD自体は何の変哲もない“白ラベル”で、特筆することはない。お決まりのCrystalDiskMarkとCrystalDiskInfoの結果を貼っておく。

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):   216.271 MB/s [    206.3 IOPS] < 38555.55 us>
  SEQ    1MiB (Q=  1, T= 1):   215.477 MB/s [    205.5 IOPS] <  4862.16 us>
  RND    4KiB (Q= 32, T= 1):     1.398 MB/s [    341.3 IOPS] < 91998.14 us>
  RND    4KiB (Q=  1, T= 1):     1.318 MB/s [    321.8 IOPS] <  3103.91 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):   216.307 MB/s [    206.3 IOPS] < 38573.18 us>
  SEQ    1MiB (Q=  1, T= 1):   215.310 MB/s [    205.3 IOPS] <  4861.94 us>
  RND    4KiB (Q= 32, T= 1):     4.309 MB/s [   1052.0 IOPS] < 30255.31 us>
  RND    4KiB (Q=  1, T= 1):     4.164 MB/s [   1016.6 IOPS] <   982.39 us>

Profile: Default
   Test: 1 GiB (x5) [F: 0% (1/14902GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2022/02/01 22:08:10
     OS: Windows 10 Professional [10.0 Build 19043] (x64)
Comment: WD Elements 16TB (WD160EDGZ)

一方で、USB接続時とSATA接続時で、なぜか総セクタ数が違うのは気になる所。

USB-SATA変換チップはJMS579で、恐らくこいつがHDDのセクタ数を実際よりも過少にOS側に報告してるのだろう。何かしら理由があって制限してるのか、チップの仕様なのかバグなのか……。GPTの場合、ディスクの終端にセカンダリGPTが配置されるため、あまり望ましい挙動とは言えないなぁ。まぁ、真っ当にUSB HDDとして使う分には問題ないし、SATAとUSBを行き来しなきゃいいだけですけども。

MyBookの変換基板はWD向けのカスタムファームで、WD, HGST以外のHDDを認識しないようになっているらしく、関係があるのかもしれない。

今回買ったHDDは10TB×5のRAID-Z2プールの置き換えに使うつもりで、現在絶賛リビルド中。実効26TiBのうち23.3TiB使用した状態でzpool replaceを行うと、resilveringに2日ちょいかかった。HDD台数的に既存vdevのreplaceを選んだが、これだけ時間がかかるなら思い切ってdRAIDに乗り換えても良かったのかもしれない。

• 【WD Elements】米AmazonでWDの外付け16TB HDDを買って『Ultrastar DC HC550』っぽいHDDを手に入れた話【WD160EDFZ】 | PC好きの備忘録
• JMS579 - Trying to find a workaround for bypassing 2021 WD MyBooks HDD DRM

近頃の毎週末は棚づくりに勤しんでいる。サボり期間を経つつ1ヵ月ほどかけて、ようやく塗装までこぎつけた。

材料の桐の調湿性を損なわないよう（効果はほとんどないと思うけど気持ちの問題）、塗料はワトコオイルのナチュラルにしてみたんだけど、これがまぁ失敗かなと。期待とは裏腹にだいぶ黄色い仕上がりとなってしまった。

言わずもがな、上が塗装後で下が塗装前。塗装後の方は、桐の白く淡い感じが完全に消えパイン材みたいになってしまった。加えて、見にくいけど塗った方の右上、シブの部分（桐材特有の紫っぽく変色した部分）が茶色っぽく強調されて、大変残念な感じに……。

古びた感じを出したい人にはいいかもしれないけど、個人的には桐の風合いが台無しというほかない。桐を含め白っぽい木にはホワイトの方が合うと思われる。どこぞで「ホワイトは白色をそのままコーティングしたような仕上がり」と見てナチュラルにしたんだけど、結果的に選択ミスだった。

ウェット研磨と乾燥を経て、少しでも落ち着いてくれることを祈るばかりですよ。

初めてワトコオイルを使ってみたけど、だいぶニオイが独特。オイル系にしてはニオイ控えめって事らしいけど、とても室内で濡れるようなレベルではない。ドクダミとミントと灯油を混ぜたような、うんにゃりとした感じ。これならシンナーのガツンと臭い方がマシだなー（個人の感想です。）

自鯖のProxmox VEを6から7に上げたら、アイドル時の消費電力が上がったような気がする。ハードウェア構成が少し変わってたりもするので何とも言えないところだが、IPMIで見る限り増えているのは確か。

あれこれ試してみたところCPUのスケーリングガバナーの挙動が変わっていた。そして、そもそもCPUドライバとしてintel_pstateではなくintel_cpufreqが使われていた。

# cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq　★これ
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.20 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

同じ環境でPVE 6の時はintel_pstateが使われていたハズなんだけどなぁ。dmesgを見ると、intel_pstateが採用されている雰囲気だが、“HWP not enabled”の一文も気になるところ。

# dmesg | grep intel_pstate
[    2.020574] intel_pstate: HWP not enabled
[    2.020580] intel_pstate: Intel P-state driver initializing

答えはArchiWikiとintel_pstateのドキュメントに書いてあった。HWP (Hardware P-States)が使えないCPUではintel_pstateはPassive Modeとして動作し、ドライバとしてintel_cpufreqが使われるとのこと。お前かー!!

Linuxカーネルバージョン5.8¹⁾でのintel_pstateの改修により、この挙動に変わったらしい。実際、v5.7とv5.8のソースを見比べると、確かにそのような変更が加えられている。

話はこれで終わらずv5.9において、EPP (Energy Performance Preference)を持たないCPUをHWP制御から除外するコードがわざわざ追加されている。HWPはSkylakeからの実装とされているが、実際はBroadwell-EPで初期実装が行われているらしく、現に前述のv5.7コードではHWPを使うようになっている。

自鯖のCPUはまさにBroadwell-EPなXeonなので、見事に該当しているというワケだった。

強制的にアクティブモードにすることもできそうだが、どっちがいいんだろうねぇ？更にHWPM (Hardware Power Management)を使って、完全にハードウェア任せにするという選択肢もあるし悩ましいところ。

(2022-02-21 追記)

うちのマシンの場合アイドル時の消費電力は、やはりアクティブモードの方が気持ち低いようだ。

アクティブモードとパッシブモードの切り替えは/sys/devices/system/cpu/intel_pstate/statusに、それぞれactiveとpassiveを書き込むことで可能。切り替えた場合、スケーリングガバナーの変更もお忘れなく。

# cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

# echo active > /sys/devices/system/cpu/intel_pstate/status

# cpupower frequency-info 
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.20 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

• Intel P-State With Linux 5.9 Adds Passive Mode With Hardware P-States - Phoronix
• intel_pstate CPU Performance Scaling Driver — The Linux Kernel documentation
• CPU frequency scaling - ArchWiki
• Linux kernel 5.8 defaults to passive mode for intel_pstate driver for cpu before skylake : linux
• [SOLVED] No intel_pstate driver since kernel 5.8.1 / Kernel & Hardware / Arch Linux Forums
• 【笠原一輝のユビキタス情報局】Skylakeの“SpeedShift”でPステートの消費電力削減を実現 ～Windows 10とSkylakeでさらなる長時間バッテリ駆動が可能に - PC Watch
• 3.2. CPUfreq Red Hat Enterprise Linux 7 | Red Hat Customer Portal

謹啓　初春のみぎり、いよいよご壮健の由、大慶に存じ上げます。

さて、日頃ご愛顧賜っております弊サイトは、2022年元日を以てクソゲ〜製作所から「のふ処」(のふどころ)に改名することとなりました。併せてドメインもnofu.jpに変わります。中身、コンテンツ、運営方針については従前通りで変更はありません。

要はただのサイト名とドメイン名の変更ですな。理由は以下の通り。

• SEO、検索性の問題
• ドメインが汚れてきた
• 地域性の明確化とドメイン名の短縮

decomo.infoは自分の名字と某大手携帯キャリアをもじって付けたものだけど、今となってはSEO的に非常に不利となっている。decomoで検索しても、あっちがサジェストされちゃうんだもの…大企業だしそれこそ重要なインフラを担ってらっしゃるので当然なんですけどね。 「クソゲ〜製作所」という名前も同様で、長音符がわりの「〜」は検索エンジンと相性が悪いっぽい。意味のある単語として認識されてないような挙動。波ダッシュ問題も影響してる気がして、非常によろしくない。

この名前は、ゲームプログラマを夢見た高校生の時代に「クソゲ〜製作所というブランドで面白いゲームを作ったら楽しいじゃん」という安直さと、クソゲーは作らないという少しの矜持を込めて付けたものだ。

それから幾年、曲がりなりにも夢は叶い、誰もが知る某有名タイトルなんかにも携わることができたが、ついぞ自分でゲームを作ることはなかった。実のところゲーム業界を離れて既に4年が経つし、ゲームという看板の降ろしどきかなと。

とはいうものの、「のふ処」の“のふ”はクソゲ〜のクを「ク→ノフ→のふ」と変化させ、“処”は製作所の「所」から来ているので全く無関係というわけではない。よりストレートな案として、当初はクソ所（くそじょ/くそどころ）もあったが、いろんな意味で直球過ぎてボツにした。個人的には嫌いではないけど、流石にメールアドレスとして公衆送信するのは憚られるのでｗ

メールアドレスの点では、decomo.infoだと冒頭の有名企業の兼ね合いでバッタもの感が強いし、20年も使ってると情報漏洩やら何やらで汚れて来るんですわ。そうなんですよ、decomo.infoは2002年3月27日に取得してるんで、今年で20年なんですよね。ちょっとビックリですよね。

そんなわけで丁度いい節目でもあるので、4文字と短く、日本発信ってのが明確で、字面と語感が何となく良いnofu.jpに移行する。

これ自体も2018年頃から考えていたもので、実際ドメインはその時に取得済み。移行作業は遅々と進まず、むしろ面倒で進める気もなかったのが実情だが、この正月休みでやっちゃおうと、ふと思い立ったが吉日ってなもんで。ついでにページのスタイルも昨今のレスポンシブな感じに。

本年もよろしくお願いいたします。