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

数年前のある日、突然Nextcloudのクライアントが「ファイルの更新日時が不正」というエラーを吐いてファイルの同期ができなくなった。確認してみると、大量のファイルの更新日時(mtime)が1970年1月1日になってるやんけえええええええ！！！！

どこをどうみてもUNIXエポックです、本当にありがとうございました。デスクトップクライアントv3.4.0でのやらかしらしい？

同期を再開させるだけなら、touchでmtimeを現在日時に更新してやればよい。でもワタクシはファイル探すときに結構mtime使うんですよね、なので極力元に戻したい。幸い、作成日時(ctime)とアクセス日時(atime)のいずれかは無事なようなので、それらからmtimeの復元を試みる。公式でmtime correction tool kitという、名前のとおりの復旧ツールが用意されているが、こちらはLinux環境向けでFreeBSDでそのまま使うことはできない²⁾ので、これらを参考に手動で直す。

まずは、mtimeが1970/1/1になったファイルを抽出する。Nextcloudのデータフォルダは/mnt/nextcloud/dataとする。

findで「mtimeがUNIX時間の0である」と指定する方法がわからなかったので、「mtimeが40年前（2024年9月時点で1984年9月）より新しい」とした。単位は分であることに注意。で、該当するファイルの作成日時(birthtime)、作成日時(ctime)、更新日時(mtime), 最終アクセス日時(atime), ファイル名をファイルに書き出す。

# cd /mnt/nextcloud/data
# find . -mmin +21024000 -print0 | xargs -0 stat -f "%SB,%Sc,%Sm,%Sa,\"%N\"" -t "%s" > /tmp/epoch_time_file_list.csv

CSVをExcelで開き、諸々整形する。UNIX時間→Excel日時の変換数式は=(UNIX時間のセル+32400)/86400+25569で、セル書式をyyyy/mm/dd hh:mm:ssとすればよい。

とりあえず、各種タイムスタンプの中で最も新しい値をmtimeとして採用することにした。どうもNextcloudに突っ込んだ時点でmtime以外の情報は消失しているような気がする³⁾ので、こんなに頑張っても仕方ないと思いつつ、現在日時にするのはなんか嫌なので。

Excelからタイムスタンプ,ファイルパスのCSVを書き出し、以下のようなスクリプトに食わせればmtime, atimeがそれなりに復旧できる。

#!/usr/local/bin/bash

while IFS=, read datetime file
do
    touch -t $datetime "$file"
done < $1

それにしてもだなー、Nextcloudがmtimeしか保持してないっぽいのは結構衝撃。デバイス間の同期が楽で、意識することなく履歴付きバックアップにもなるなーと思って建てたけど、自分の用途には合わないかなぁ…便利なんだけどさー。zipなんかも更新日時しか保持しないし、アクセス日時はともかく、みんな作成日時とか気にしないのかしら…？

他のクラウドストレージはどうなんだろう、と気になってたらDropboxとGoogle Driveを調べてる方がいた。子曰く、どちらも基本的に同期クライアントを使った場合は更新日時は保持されるとのこと。デスヨネー。

結局、ファイル属性含めて保持しておきたいなら、ローカルストレージかSMBでせっせとバックアップするしかないのかねぇ。理想の形はMacのTimeMachine。設定したら知らぬ間にバックアップがとられてて、イザって時に大助かりというやつ。WindowsもVSS（復元ポイント）で似たようなことはできるが、如何せんUIがダメダメすぎる。TimeMachine並にイケててリッチにしろとは言わないが、ファイル/フォルダのプロパティに押し込まれててアクセス性が最悪すぎる。

かといってOneDriveは仕様が素晴らしすぎて全く使う気になれないし。

Windowsのバックアップソリューション、もっとなんとかならんものか。

• Desktop client 3.4.0 destroys local time stamp and keeps uploading data to server - 📱 Desktop & mobile clients - Nextcloud community
• GitHub - nextcloud-gmbh/mtime_fixer_tool_kit: Tool kit to fix the mtime issue on the server state
• 多分すごく分かり易い！UNIXTIMEをエクセルで扱う方法 - まるノート
• 【備忘録】ファイルの更新日時を維持したまま、オンラインストレージに預けたり取り出したりしたい！｜犬川さと

freebsd-updateなどでシステム更新の際、手順ミスでライブラリに不整合が生じることがある。Shared object “libxyzw.so.8” not found的なアレ。

これがログインシェルで起きると悲劇で、シェルの起動に失敗しシステムにログインできなくなってしまう。マシンに物理アクセス可能ならシングルユーザーモードなりで復旧可能だが、アクセス手段がsshとかしかなかったりすると詰むんですわ。お察しの通り、記事にしてるくらいだから実際に詰んだんですけどね。

実家サーバをfreebsd-updateが中途半端な状態で再起動したら、以下のような状態でsshログイン不可になってしまった。

$ ssh Decomo@192.168.0.1
Password for Decomo@:
Last login: Sun Nov  6 13:06:52 2022 from 192.168.0.2
FreeBSD 13.1-RELEASE-p1 GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "fish"
Connection to 192.168.0.1 closed.

ログインシェルの変更さえできればリモートアクセスできそうなものの、ssh経由で実現する方法はついぞ見つけられなかった。実のところ作業自体は11月の実家帰省中に行っており、目の前にマシンも液晶モニタもあるのに、D-Sub→DVI-Iのケーブルがなく、手も足も出なかったという。この度、ケーブル持参でようやく復旧できたというわけ。

そもそも、リモートアクセス手段しかない状態でシステム更新すんなよって話だが…静的リンクなbashであるbash-staticがPortsに存在する理由を“わからせ”られた。

というわけで、動的リンクなシェルをログインシェルにしてはいけない。どうしても設定する場合は、/bin/shをログインシェルとするリモートアクセス可能な緊急回復用ユーザー⁴⁾を作っておくと良いだろう。

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