今まで気づかなかったが、2か月ほど前の6/11に、待望のRAIDZ ExpansionのプルリクがOpenZFSに立てられていた！！2018年のプリアルファコード以来目立った動きがなく、どうなっとんじゃーいって感じだったが、June 2021 FreeBSD Developer Summitでの報告の翌日、PRが作られた模様。

コードレビューは始まったばかり、というかまだ進んでない？ようでリリースはまだまだ先っぽい。OpenZFSプロジェクトの状況としては、現在は2.1リリース作業の真っただ中で、取り込まれるのはどんなに早くとも来年リリースのOpenZFS 2.2あたりと見込まれている。まぁ、かなり大きい変更なのでレビューもテストも時間がかかるだろうしね、仕方ないね。

PRの議論を見るに、拡張時の挙動である「既存データのストライプサイズは変更しない＝データ/パリティ比率は変わらない」という点が、結構引っかかってるっぽい雰囲気。

RAIDZ ExpansionでRAIDZ vdevにストレージを追加した場合、vdevの物理ストライプ幅は拡張後のサイズとなる。対する論理ストライプ幅については、既存のデータは拡張前の幅、再書き込みを含む新規データは拡張後の幅となる。具体的な数値を当てはめると、HDD 5本のRAIDZ2プールをHDD 6本に拡張した場合、既存データは論理5ストライプ（データ/パリティ比=3:2）のままで、新規データは論理6ストライプ（データ/パリティ比=4:2）で記録される。データによってストライプ幅が異なること自体は、RAIDZの元からの仕様なので問題ないらしい。

一方で、この仕様のため既存RAIDZプールの使用率が高いほど、RAIDZ Expansionでのプール拡張後の実効空き容量は増えにくくなる。例えば、1TB×4のRAIDZ1プールに1TB書き込むとプール使用率は33%なのに対し、1TB×3のRAIDZ1プールに1TB書き込んだあと（この時点での使用率は66%）で1TBのHDDを追加しても使用率は66%のままとなる。既存データのデータ/パリティ比が変わらない以上、この容量オーバーヘッドは避けられない。

RAIDZ ExpansionでRAIDZプールは何度でも拡張可能だが、こんな感じゆえに、最小構成で始めて必要に応じて後からディスクを追加する、という戦略は取りにくいのは否めない。

使っていく中で既存データも新しいストライプ幅に置き換わり、このオーバーヘッドは徐々に解消されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい！という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか？そもそもZFS的にはそんなカツカツ運用するなよって感じ？

拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の簡便さと拡張中のRAIDZ1/2/3の冗長性担保が理由とのこと。

このまま無事マージされて欲しい。

• RAIDZ Expansion feature by ahrens · Pull Request #12225 · openzfs/zfs · GitHub
• ZFS fans, rejoice—RAIDz expansion will be a thing very soon | Ars Technica
• DevSummit/202106 - FreeBSD Wiki
• ZFS RAIDZ expansion is awesome but has a small caveat
• RAIDZ expansion and dRAID excellent OpenZFS adventure - Storage Gaga

PC仮想化において、ストレージコントローラの準仮想化デバイスの選択肢はvirtio-blkとvirtio-scsiの2つがある。名前のとおり前者が仮想ブロックデバイスコントローラ、後者は仮想SCSIコントローラである。

SCSIレイヤを通らない分、virio-blkの方が多少性能面では有利なようだが、以下の理由により基本的にはvirtio-scsiを使った方が良いらしい。

• virtio-blkは1ゲストあたり最大28デバイス＝28ストレージに制限される
  • virtio-blkとストレージは1:1の関係でPCIデバイスとなるので、PCIバス規格の制約を受ける。
  • 他のPCIデバイス（NICなど）との兼ね合いで、実際はより少ないデバイス数となる。
  • 対するvirtio-scsiは1デバイスで数百のストレージを扱える
• virtio-blkでは一部のストレージのエミュレーションができない（光学ドライブなど）
• virtio-blkはホットスワップ非対応
• vitrio-scsiの方が開発が活発

virtio-blkで割り当てたデバイスは、ゲストからも当然ブロックデバイス扱いとなり、例えばストレージデバイス表示コマンドなどで出てこないことが多々あるため、少しわかりにくいという個人的な感覚があったりする。

• virtio-blk vs virtio-scsi · mpolednik.github.io
• Understanding of virtio-scsi and virtio-blk - Programmer Sought
• Difference between virtio and virtio single controller types? | Proxmox Support Forum

動作音の静かなサーキュレーターを求めて、無印良品の「サーキュレーター（低騒音ファン・大風量タイプ）・ホワイト AT-CF26R-W」を買った。

今夏、うちでは北側設置の2.2kWエアコン1台で、70㎡の部屋全体を冷やすということをしている。畳数でいえば、6畳用で20畳以上のエアーコンディションをしていることになり、冷気の循環のためにサーキュレーターが欠かせない。そんなので冷えるの？と思われるだろうが、意外や意外、これが結構快適なんですわ。問題なく冷えるし、冷風が体に直接当たらないのもよい。カタログの畳数表記は断熱が一切されていない建物での値で、昨今の高断熱の住宅ではあまり意味のない値となっているらしい。

そもそも、何でこんな変なことをしてるかと言うと電気代節約のため。

本来の主エアコンであるリビングの4.5kWエアコンは、2.2kWエアコンよりCOPが2も低い。加えて室外機が南側のため、北側と比べ効率は更に落ちると考えられる。実際、日々の電気使用量を比べると、2.2kWエアコン運用にしてから10～15%程度の節電になっているようだ。4.4kWだと間欠運転になりがちなところ、2.2kWだと適正負荷の連続運転となっているのも影響しているのだと思われる（根拠なし）。

これまでアイリスオーヤマの18cmサーキュレータ PCF-HD18-Bを使っていたのだが、1日中回してると風切り音が気になってくる。そんなわけで、静音と評判で値段も手ごろな無印良品のサーキュレータを買ったという次第。

無印良品のサーキュレータは、26cmファンのAT-CF26R-W（今回買ったやつ）と18cmファンのMJ-CF18JP-Wの2機種がある。

18cmモデルは結構頻繁にモデルチェンジしており、現行モデルは以前よりも風量が増え、静音化が進んだ模様。26cmモデルは2013年の発売から変わっておらず、そろそろモデルチェンジしそうな気もするけど、風量・静音ともに未だ18cmモデルより優れている。どちらにするか非常に悩んだものの、

• 大は小を兼ねる
• 風量は正義。だってサーキュレータ―だもの。
• 大きいファンを低速回転させるのが静音化の基本

というわけで、26cmモデルのAT-CF26R-Wを選んだ。

以下はPCF-HD18-Bと比べた時のAT-CF26R-Wの感想。

• 静か！
  • 弱運転時の静音性は特筆に値する。ほぼ無音なのに、しっかりと風が感じられてスゴい。断続的に吹くそよ風、という感じで就寝時に最適。
  • 中・強運転時は相応に音はする。けれども、PCF-HD18-Bより音域が低めなので耳障り感が全然違う。例えるなら「ブオォンォンォン」に対して「ゴオォォォォ」って感じ。
• 風の直進性がいい
  • 前述のとおり、弱運転でもしっかりと風が来る
  • それでいて大型ファンのためか、風の面積が広く風当りが柔らか
• 設計寿命が10年
  • 安心のメルコエアテック（三菱の空調系子会社）製。やるじゃん三菱。

• 風量切り替えが3段階
  • 弱→中で風量・ノイズレベル共に一気に上がる
  • カタログ値も2倍以上違っており、体感としても全く違う。少し音がするけど弱より多い風量の段階があると、更に活用の幅が広がりそう。
• 微妙な風向調整ができない
  • 0～90度の5段階でストッパーが掛かるようになっている。中途半端な位置で止めようとしても自重で落ちてしまうため、規定位置以外での風向調整は無理っぽい。
• 首振りがない
  • 納得の上で買ってるのでダメって程ではないけど
  • 大型ファンの威力で風の面積が広いので、無くてもさほど不便はしない感じ
• でかい！
  • ファン自体が大型なので仕方がない。納得の上で買ってるので個人的には気にならない。
  • 脚がファンから真下に生えてるタイプなので、両側から生えてるタイプ（アイリスオーヤマで言うところのH型）より逆にスッキリしてると思う

AT-CF26RとPCF-HD18の消費電力は下表のとおり。ワットチェッカーTAP-TST5での実測値。

• 無印良品 サーキュレーター 騒音レベルを実測、その静かさに驚く！: Sound of TOON
• 無印良品のサーキュレーターは大小どっちを選ぶべきか？ | 一条工務店で建てたまぼこのきろく

唐突にアーロンチェアのポスチャーフィットが気になってきた。

ポスチャーフィットの詳細は割愛するが、ハーマンミラーの日本法人がチェアのオーバーホールサービスのオプションとして、ポスチャーフィット化を行っている。料金は33300円+往復送料(12100円～)(2021年7月現在)と、サービス内容を考えれば妥当な価格と思いつつも、中古でアーロンチェアが買えてしまう金額である。

うちのアーロンは2018年に購入した中古品。貧乏なので。とか言いつつ今使ってるのは2台目。アーロンならどれも一緒だろうと買った1台目は座高調整機能だけの梅モデルで、固定ひじ掛けがどうしても許せず売却。その後、入念な下調べを行い、この時に海外では自分でポスチャーフィット化する公式キットがあることも知ったんだけど、ランバーサポートタイプのフル機能モデルに買い替えたという、安物買いの銭失いな経緯があったりする。

コロナ対策の在宅勤務で、以前よりアーロンチェアに座ってる時間が長くなってることもあり、ポスチャーフィット化することにした。ランバーサポートは経年で割れることが知られており、長い目で見ればポスチャーフィットの方がいいだろうし、ランバーサポートが健在な今なら売っぱらってポスチャーフィット化費用の足しになるだろうっていう目論見。

前述の通り、公式サービスに頼むと価格がぴえんでぱおんなので、先達に従ってポスチャーフィットキットを個人輸入し、自分で取り付けることにする。検索で出てくる事例はいずれも古めの情報なので、最近のポスチャーフィットキット事情としてまとめておく。

2021年3月現在、ポスチャーフィットキットの入手は転送サービスを使って個人輸入するしかなさげ。以前は国内業者が並行輸入したものを販売していたようだが、現在は軒並み在庫切れとなっている。

キット自体は現行品で、アメリカ本国ではハーマンミラー公式直販でも売っているものの、日本から買うのは無理っぽい。クレカのBilling Addressが不正となり先に進めない。現地クレカしか使えないっぽい？PayPal対応ということにもなっているが、どう頑張ってもクレカ払いしか選べず完全なる無駄足に終わった。会員登録までしたのに！

残された道は再販業者（普通の販売店）からの購入となるが、残念ながら手ごろな送料で日本に直送してくれる販売店は見当たらなかった。

幸いAmazon.comマケプレで取扱があったため、お手軽かつ一定の安全性も担保されてると判断し、その業者から買うことにした。

日本に送ってくれるマケプレ業者は少ないため、転送サービスを使うことになる。直送できても転送サービスの経由の方が安いパターンもあるので、この辺は臨機応変に対応する。

転送サービス業者選定のポイントは、オレゴン州の倉庫を使えるかどうか。

アメリカでは州によって売上税（消費税）がまちまちで、最大10%ほどになる。オレゴン州は0%のためオレゴン以外を選ぶ理由がない。売上税がかかる州の倉庫は、たいていサンフランシスコやカリフォルニアの倉庫だけど、日本までの送料が少し安かったり、配送時間が短かったりというメリットがあるにはある。ま、そんなものより、目先の金が大事なのさ～。

というわけで、今回はスピアネットを使った。

当初は使ったことのあるGooppingを使う気でいたけど、今はShipitoに吸収され肝心のオレゴン倉庫が月額会員じゃないと使えなくなったようなので、お役御免となった。

日本時間の3/13に注文し、3/26に受け取ることができた。ざっと2週間、可もなく不可もなく平均的なスピードかなと。

スピアネットは基本的に国際発送から国内配達まで一貫してヤマト運輸の取り扱いのことが多いようで、何となく安心感があった。到着までの詳細は下表のとおり。

ヤマトの履歴はこんな感じ。

ポスチャーフィットキットの個人輸入にかかった費用は下表のとおり。商品代含めておよそ2万円となった。

実際のところ、600ドルのSSDも同梱して転送したため、その分の手数料が含まれている。特別梱包のためか、えげつない量の梱包材が入ってて荷物サイズが大きくなった分も差し引くと、17000円くらいで収まるかも？

2014年頃はポスチャーフィットキットが80ドル程度だったのに加え、円高で結構安く変えたっぽい。このところ、あれよあれよと円安に振れてて怨めしい……。

eBayなどで個人輸入は何度も行っているが、転送サービスを使ったのは今回で2度目、スピアネットは初めて使ったが明朗会計で値段相応の仕事をしっかりしてて好印象だった。何よりオレゴン倉庫が使えるのが嬉しい。やり取りは日本人スタッフと日本語で行えて楽だし、レスポンスも良いので今後も使っていくと思う。

思う所があってマルチプラットフォームなメディアプレーヤーQMPlay2をWindowsで自前ビルドした。公式にWindows用ビルドが提供されているので、自前ビルドしようっていう物好きな人はそういないだろうけど、参考になればとメモがてら手順を書いておく。

• Windows 10 (x64) 20H2
• msys2
• MinGW-w64
• GCC 10.3.0
• QMPlay2 21.06.07-gti-417708b8

とりあえずmsys2のインストールとパッケージ更新までは済ませておく。

以下の作業はMinGW-w64環境（MSYS2インストールディレクトリのmingw64.exe起動で出てくるシェル）で行う。

コンパイラ、開発環境類をインストール。

pacman -S base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake

注意すべきはcmake。msys2リポジトリにもcmakeがあるが、こちらはファイルパスの扱いがUNIXスタイルとなるため、mingw-w64リポジトリのソフトで正しく扱えない。したがって、Windowsスタイルのファイルパス用のming-w64のcmakeを使う必要がある。

gitをインストール

pacman -S git

Qtをインストール

pacman -S mingw-w64-x86_64-qt5

FFmpegをインストール。これだけでビルドに必要な最低限のライブラリは殆ど自動で入った記憶。

pacman -S mingw-w64-x86_64-ffmpeg

PortAudioをビルド。MinGWにビルド済みパッケージがあるけど、WASAPIが有効になってないので自前ビルドする必要がある。tarballの取得と展開は割愛。

cd portaudio
/mingw64/bin/cmake .. -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=/mingw64 -DPA_USE_WMME=1 -DPA_USE_WASAPI=1 -DPA_USE_DS=1 -DPA_USE_WDMKS=1 -DMINGW=1
make -j8
make install

ここまででQMPlay2をビルドする環境が整った。

ソースコードとサブモジュールを取得。

git clone https://github.com/zaps166/QMPlay2.git
git submodule update --init

ビルドディレクトリを作ってcmake。cmakeは前述の通りmingw64のバイナリを明示的に使い、加えてMakefileを生成したいので-Gでオプションが必要。さもないとVisual Studio用のソリューションファイルが生成されてしまう。

cd QMPlay2
mkdir build
cd build
/mingw64/bin/cmake .. -DCMAKE_INSTALL_PREFIX=../install -G"MSYS Makefiles"

上手くいけば↓こんな感じでcmakeが成功する。

-- Could NOT find TAGLIB (missing: TAGLIB_LIBRARY TAGLIB_INCLUDE_DIR)
-- Could NOT find LIBGME (missing: LIBGME_LIBRARY LIBGME_INCLUDE_DIR)
-- Enabled features:
 * Updates, Build with software updates
 * OpenGL, Build with OpenGL support
 * Vulkan, Build with Vulkan support
 * libass, Build with libass support
 * Inputs, Build with Inputs module
 * Modplug, Build with Modplug module
 * Extensions, Build with Extensions module
 * MediaBrowser, Build with MediaBrowser support
 * LastFM, Build with LastFM support
 * Lyrics, Build with lyrics support
 * Radio, Build with Radio Browser support
 * YouTube, Build with YouTube support
 * Visualizations, Build with Visualizations module
 * AudioFilters, Build with AudioFilters module
 * VideoFilters, Build with VideoFilters module
 * PortAudio, Build with PortAudio module
 * DXVA2, Build D3D11VA acceleration into FFmpeg
 * CUVID, Build with CUVID module
 * Notifications, Build additional notifications module
 * Git version, Append Git HEAD to QMPlay2 version

-- Disabled features:
 * PCH, Use precompiled headers
 * CMD, Show CMD when running QMPlay2
 * GLSLC, Compile Vulkan shaders
 * TagLib, Build with tags editor
 * VAAPI, Build VAAPI acceleration into FFmpeg
 * VDPAU, Build VDPAU acceleration into FFmpeg
 * libavdevice, Build FFmpeg with libavdevice suport
 * AudioCD, Build with AudioCD module
 * ALSA, Build with ALSA module
 * Chiptune GME, Build Chiptune with GME support
 * Chiptune SIDPLAY, Build Chiptune with SIDPLAY support
 * PulseAudio, Build with PulseAudio module
 * PipeWire, Build with PipeWire module
 * XVideo, Build with XVideo module
 * Link Time Optimization, Enable link time optimization for release builds
 * Address Sanitizer, Use Address Sanitizer
 * Undefined Behavior Sanitizer, Use Undefined Behavior Sanitizer

-- Build type: Release
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Home/proj/QMPlay2/build

「TagLibとGMEがない」と怒られるが、必須ではないので問題なし。必要ならpacman -S mingw-w64-x86_64-taglib mingw-w64-x86_64-libgmeしとけばいいかと。

必須ライブラリがない場合、怒られてcmakeに失敗するので頑張って対処する。

makeとインストール。

make -j8
make install

上手くいけば、CMAKE_INSTALL_PREFIXで指定したフォルダ、ここでは../installにQMPlay2.exeなどがコピーされる。

PATHの関係でエクスプローラからexeダブルクリックでは起動できないため、ビルドしたシェルに../install/QMPlay2.exeと打ち込んで起動する。試してないけど、必要なDLLをexeと同じ場所に置いたり、PATHにmingw64/binを通せばエクスプローラからでも起動できると思う。