以前、FreeBSDではlongnameフィーチャーは使えないという話をした。

FreeBSDで255バイト超のファイル名でファイルは作れないとして、Linuxで作った256バイト以上のファイル名を持つZFSをFreeBSDにインポートした場合、どうなるのだろうか。インポートできなかったり、クラッシュしたり、データセットが壊れるなんてことは流石にないと思うが、分からんってのが正直なところ。サクッと試してみよう。

まずはLinux側でlongnameフィーチャーが有効なデータセットと、長いファイル名を持つファイルを作る。

環境はこんな感じ。Linuxと言いつつProxmox VEです。

# pveversion
pve-manager/9.1.4/5ac30304265fbd8e (running kernel: 6.17.4-2-pve)

# zpool version
zfs-2.3.4-pve1
zfs-kmod-2.3.4-pve1

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

        NAME                      STATE     READ WRITE CKSUM
        zlongname                 ONLINE       0     0     0
          zvol/zvm/vm-100-disk-0  ONLINE       0     0     0

errors: No known data errors

データセットの文字コードはUTF-8にした。

# zfs create -o utf8only=on zlongname/longname

UTF-8の場合、日本語1文字はおおむね3～4バイトでエンコードされるので、255バイト=全角85文字となる。255バイトと256バイトのファイル名でファイルを作ってみる。

# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５'
# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a'
touch: cannot touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a': File name too long

256バイトの方はファイル名長すぎィと怒られた。longnameフィーチャーを有効にして再度試してみる。

# zfs set longname=on zlongname/longname
# touch '１２３４５６７８９~1~１２３４５６７８９~2~１２３４ ５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６ ７８９~7~１２３４５６７８９~8~１２３４５a'
# ls
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a

今度は当然ながら問題なく作成できた。このプールをFreeBSDに持っていく。

FreeBSD側は以下のような感じ。ashiftの警告が出てるけど本質じゃないのでスルーで。

$ freebsd-version -uk
14.3-RELEASE-p2
14.3-RELEASE-p2

$ zpool status zlongname
  pool: zlongname
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
config:

        NAME                                          STATE     READ WRITE CKSUM
        zlongname                                     ONLINE       0     0     0
          gptid/737d89da-f0e3-6c4d-a86d-426d41479aa8  ONLINE       0     0     0  block size: 512B configured, 4096B native

lsでは普通に255バイト超のファイル名も表示された。ちょっと意外。

$ ls /zlongname/longname/
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５
１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a

開こうとするとファイル名長すぎィと怒られた。

$ cat '/zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a'
cat: /zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５a: File name too long

256バイトのファイル名でファイルを作ろうとしても、やっぱり長すぎィと怒られた。

$ touch '/zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５b'
touch: /zlongname/longname/１２３４５６７８９~1~１２３４５６７８９~2~１２３４５６７８９~3~１２３４５６７８９~4~１２３４５６７８９~5~１２３４５６７８９~6~１２３４５６７８９~7~１２３４５６７８９~8~１２３４５b: File name too long

というわけで、ZFSのlongnameフィーチャーを有効にし256バイト以上のファイル名があるデータセットをFreeBSDに持っていくと、ファイルの存在は確認できるが、ファイル操作は不可というのが現状のようだ。

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に鞍替えするときが来たのか!?