AinexのAIF-12は、USBを計7ポートを増設可能なPCI Expressカードである。ポートの内訳は下記の通りで、USB 3.0とUSB 2.0の両方のピンヘッダを備えた、なかなかわかっとるじゃないか仕様となっている。

• 外部
  • USB 3.0 Type-A 2ポート
• 内部
  • USB 3.0 Type-A 1ポート
  • USB 3.0 ピンヘッダ（2ポート分）
  • USB 2.0 ピンヘッダ（2ポート分）

値段も3000円ちょいとお手軽価格。

採用チップの情報は公式サイトに書かれておらず、ネットを彷徨っても発見できず。商品画像からμPD系とGL3523が載ってそうな雰囲気はあるものの、不明瞭で確証が持てなかった。

諸事情で内部USB 2.0ピンヘッダが欲しく、ほかに選択肢もなかったのでダメもとで購入した画像がこれ。

ばっちりμPD720201とGL3523ですな。

パターンを追ってみると、Type-A 3ポートはμPD720201に直結、それ以外はGL3522のハブ経由の模様。まとめると以下のトポロジーになるっぽい。

uPD720201
├ 外部 3.0 Type-A
├ 外部 3.0 Type-A
├ 内部 3.0 Type-A
└ GL3522
　├ 内部 3.0 ピンヘッダ
　├ 内部 3.0 ピンヘッダ
　├ 内部 2.0 ピンヘッダ
　└ 内部 2.0 ピンヘッダ

OpenZFS 2.3.0で、個人的に待望のlongnameフィーチャーがリリースされた。

ZFSにおけるファイル名・ディレクトリ名（以後、まとめてファイル名と表記する）の最大長は、UNIX系の習わし(?)に沿って255 bytesとなっているが、longnameフィーチャーを有効にすると、その制約を打ち破って1023 bytesまで使えるようになる。単純に上限が固定的に引き上げられるといったものではなく、255 bytes超の名前があると機能がアクティブとなり、無くなれば非アクティブになるといった、動的な挙動となっているようだ。

この255バイトという伝統的な値はNAME_MAXマクロに由来し、FreeBSDの場合は/usr/src/sus/sys/syslimits.hで定義されている。厳密にいうと、ZFSでの制約は自身が定義している定数由来なのだが、NAME_MAXを意識した値であろうと思われる。なお、ここで注意が必要なのは、ファイルパスの最大長はPATH_MAXと別に定義されており、FreeBSDの場合は1023バイトとなっている。本記事で取り扱うのは、あくまでファイル名の最大長の方である。

現代的なUNIX系のファイルシステムでは、必ずしもこの制限に縛られることはないようだが、有名どころのFSは大抵255バイトが上限となっている。

255バイトもあって何が不満かと言われれば、ファイル名の文字エンコーディングにUTF-8を採用すると、最大文字数がだいぶ心許ないってこと。UTF-8の場合、日本語の文字は大半が3バイト、場合によっては4バイトで表現されるため、いわゆる全角換算で85～63文字に目減りしちゃうんですな。この問題はとりわけWindowsとファイル共有した時に顕在化しやすい。というのも、Windowsの主要FSの最大長はUTF-16で255文字¹⁾なので、つい長い名前つけちゃって、FreeBSD+Sambaな共有フォルダにコピーしようとして失敗、なんてことが年に数回起きる。これが1023バイトならUTF-8でも341～255文字となり、大変都合がいいわけですよ。

そんなわけで、longnameフィーチャーには大変期待していたのだが、どうもFreeBSD 14.3-RELEASE時点では事実上使えないようだ。

ZFS自体の255バイト制限はなくなったものの、FreeBSDのVFSレイヤーに255バイト制限が残っていて、この影響を受ける模様。実際、PortsからOpenZFS 2.3.0入れて試してみたが255バイト制限は突破できなかった…。SambaはNAME_MAX等の直接的な制限は受けないようだし、Linux+Sambaでは問題なく機能しているようだし、やはりFreeBSD側の制限の可能性が大。

VFSの根っこの部分っぽいし、改善されるのかなー？

正直、longnameは今すぐにも使いたい。というか、256バイト以上のファイル名を含むデータセットをFreeBSDに持ってきた時に変なことにならないんだろうか…？ついにLinuxに鞍替えするときが来たのか!?

こちらのページによれば、Western Digital Ultrastar DC SN640 U.2 NVMe SSDシリーズの初期ファームには、まれにSSDがタイムアウトし、機能不全を引き起こす可能性のあるバグがあるらしい。回復手段はSSDのフォーマットで、言わずもがなデータは失われることになる。あな恐ろし。

配布されている修正版ファームウェアはR1110021, R1410004で、手持ちのSN640はR1110012なので発生する可能性がありそう。というわけで更新してみる。

やり方は上記サイトに書いてある通り。Linux環境ならnvmeコマンドでSSDのFWをダウンロードし、適用し、マシンを再起動する。

nvme fw-download /dev/nvme0 --fw=FW.vpkg
nvme fw-commit /dev/nvme0 -a 1

こんな感じでR1110021に更新されていることが分かる。

# nvme list | grep WUS4
/dev/nvme2n1    /dev/ng2n1    A06F8XYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021
/dev/nvme1n1    /dev/ng1n1    A066EXYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021
/dev/nvme0n1    /dev/ng0n1    A0647XYZ    WUS4BB076D7P3E3    1    7.68  TB /   7.68  TB    4 KiB +  0 B    R1110021

なお、このSN640たちは例によって中古で、いずれも2PB以上読み書きされている。データシート上の寿命は11210TBW（4kランダムライト時）であるから、S.M.A.R.T.が示すとおりまだまだ余裕がありそう。

CrystalDiskMarkとCrystalDiskInfoの結果は以下の通り。PCIeパススルーでVMで測定したものなので、値は参考程度に。

------------------------------------------------------------------------------ CrystalDiskMark 9.0.1 x64 (C) 2007-2025 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): 2794.207 MB/s [ 2664.8 IOPS] < 2999.14 us> SEQ 128KiB (Q= 32, T= 1): 3284.428 MB/s [ 25058.2 IOPS] < 1272.22 us> RND 4KiB (Q= 32, T=16): 600.710 MB/s [ 146657.7 IOPS] < 615.42 us> RND 4KiB (Q= 1, T= 1): 38.750 MB/s [ 9460.4 IOPS] < 105.45 us> [Write] SEQ 1MiB (Q= 8, T= 1): 2009.656 MB/s [ 1916.6 IOPS] < 4162.21 us> SEQ 128KiB (Q= 32, T= 1): 2015.298 MB/s [ 15375.5 IOPS] < 2077.10 us> RND 4KiB (Q= 32, T=16): 523.224 MB/s [ 127740.2 IOPS] < 237.16 us> RND 4KiB (Q= 1, T= 1): 140.593 MB/s [ 34324.5 IOPS] < 28.90 us> Profile: Default Test: 1 GiB (x3) [E: 0% (0/7154GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2025/06/22 13:52:58 OS: Windows 10 Pro 21H2 [10.0 Build 19044] (x64) Comment: WD SN640 7.68TB (WUS4BB076D7P3E3) on VM

シーケンシャルは概ねデータシートどおりだが、ランダムのIOPSが1/2～1/3と振るわないのはパススルーの影響なのかしら？

• Western Digital SN640 firmware updates R1110021 and R1410004 - Thomas-Krenn-Wiki-en
• thomas-krenn/SN640-FW-Update