今度こそnetatalkすてすて…？

obsolute Netatalk

netatalkが3.1.12(2018/12)からアップデートが止まったまま。

既に死亡宣告されたPhython2系に依存してる上に、portsとしても2020-09-15には削除予定とマークされてしまってます。

追記：4/27付でPython3.x対応にportsとして更新さてました。

少なくともFreeBSD上では、時々発生する原因不明のSignal11によるcore落ち、不定期におかしくなるEAなど問題山積み。

これはもう、今度こそ捨てるしか無いと決意。

今時のmacOS(Mojave)のafp/smb事情

macOS側としても、ファイル共有への接続がsmb優先になって久しく、このままafpは消えていくんじゃ無いかとも言われてます。

xNIX界隈のmacユーザーに対する認識も「もうsambaあれば十分でしょ？」って雰囲気を感じますが、そう簡単な話でもない。結論から言うと、今時のmacOSにとってsmbはafpを完全に置換え出来ていないし、たぶん今後もずっとそう。

恐らく使っているAPIに依存するのだと思うのですが、ローカルDBを持つアプリ（iTunesとかPhotosとかFinalCutProとか）なんかだと、ファイル共有上でまともに使えるのは、afpしか無いんですわ。

smbはというと、どうもローカルファイルシステムやafpより格下の扱い。ファイルパス指定でなんとなくsmb上のファイル指定できちゃったりするけど、そんなことするとDBに不具合続出。

そもそもそういうアプリは、アプリからファイル選択ダイアログ上開くとafp共有は見えても、smb共有はマウント済みの物も含めて選択出来なくなっています。

案1-ファイル共有経由のSparse image

そんなわけで苦肉の策として、smb上にSparse imageを置き、Sparse image内をAPFSでフォーマットして各ライブラリを配置することに。TimeMachineがやってるやり方ですね。

smb共有をマウントしてからSparse imageを又マウントする訳で、最初に開くまでえらく時間が掛かるんですが、iTunesでライブラリとしてSparse image内のディレクトリを指定しておくと、かってにsmb共有からマウント初めてくれるようです。

Sparse bandle imageとFinderのバグ?の罠

今時ならインクリメンタルバックアップ対応なSparse bandle imageでイメージファイル作成したいところですが、ここにFinder側？の罠が。

Sparse bandle imageで容量が増えてくると、bandsディレクトリ内のファイル数が膨大な数に増えていきます。

どうもね、macOSからsmb共有上にある1ディレクトリ数万件のディレクトリを開くと、smbの接続が強制的に切断されてしまいます。

Windows10からだとそんなことなかったので、どうにもmacOS(10.14.6/Mojave)側のバグ臭い。Catalinaだとどうなんでしょうね。使ってないから知らんけど。

で、Sparse bandle imageだとどうなるかというと…、

• Finderからimageをダブルクリックして開こうとすると、マウント中にsmb共有が切断されて失敗する。（マウントできない）
• バックアップしようとimageファイル自体をHDDなどにコピーしようとすると、コピー前にsmb共有が切断されて失敗する。（コピーできない）
• ディスクユーティリティ.appからimageを開くとマウント出来る。
• image内のファイルに張ったエイリアス経由でなら、問題なくマウントされる。
• マウントさえ出来てしまえば、中のファイルアクセスには問題無さそう。

…と、こんな感じ。実用上は問題無さそうだけれども凄く気持ち悪い。

そんなわけでbandleじゃないSparse imageに。ZFSならブロック単位で変更点のスナップショット取ってくれるし。

案2-iSCSIを使う

まぁSparse imageでとりあえずは使えるんですが、ファイル共有の先のイメージファイル開いているもんだから「割と遅い」。

近頃のmacOSでは、互換性の高いafpを放り投げつつ、smbの対応も互換性は格下の扱い。そもそもAppleとしてネットワーク上のストレージどうしたいん？って考えてみると「ファイル共有」ではなくて、SANを使えってのが回答なのかと思い至る。

でもApple謹製のXsanだと個人で使うにはかなり敷居が高い。もっと手軽に…となるとiSCSIに行き着く。

これならOSから見れば、互換性の面ではローカルディスクと遜色ない。

iSCSIイニシエーター

• iSCSIInitiator
• globalSAN The iSCSI Initiator for macOS/OS X

macOS用で使えそうなのはこの二つ。フリーなのはiSCSIInitiatorなんですが、1年半くらい更新が無く、うちのMojaveにはエラーが出てインストールできませんでした。

ちょいお高いんですが、ちゃんとCatalinaまで対応してるglobalSANのを使いました。

GUIあって設定は簡単。

iSCSIターゲット

FreeBSDに付いてくるctld、ボリュームはいつものzfsで。

容量ケチりたいんで、zfs create -sVってして大きめにサイズ割り当てて見るも、後述のAPFS使うと台無し。

4TBの割当てして、2TB書込み＞2TB消去＞また2TB書込み…ってしようとしたら、zfs側の消費が4TBめい一杯まで増えてる感じ。

APFSではCoWみたいなことするから、APFS上に空き容量あっても読み書きしているうちにzfsの割当て使いきっちゃう様で…。

APFSのサイズ可変機能が便利

iSCSI上のボリュームはAPFSでフォーマットしました。なんでAPFSなのかというと、再フォーマット無しにパーティションサイズを可変できるから。

ディスクユーティリティ.appからはイマイチ操作しずらくコマンドラインのdiskutilの方が直感的に扱えるんですが、中身を維持したままリサイズ可能。十分な空き領域があるなら縮小も可能。

サーバー上の空き容量が心許ないので、いっぺんにiSCSI用に容量割当てするわけにも行かなかったんですが、これでNAS上のiSCSI領域割当てを使用状況に応じて可変出来ます。

そして結論

• アプリのDB→iSCSI
• ただのファイル→Samba(+vfs_fruit)
• TimeMachine→Netatalk継続

こんな感じに

アプリのDB

iSCSIでちょびっとベンチマーク取ったら、Read系はかなり早いんですがランダムライトが異様に遅い。それと、ほぼ毎日macを持ち出してるんですが、その時のmount/unmountもちょっとやりにくい。

使い勝手の面から行くとSparse imageで行きたい所ですが…って、そうするつもりだったんですが、ちょっとUnmountせずにLAN切断しちゃったらSparse imageが吹っ飛んだ…。

それはもう、FirstAidで復旧も出来ずマウントすら出来ないくらい完膚なきまでに…。（壊れる直前のsnapshotあったから事なきを得ましたが…）

そういえばTimeMachineも、数ヶ月に1回くらいのペースで壊れてたんですよね。バックアップなので、またオリジナルから取り直せば良いや…と、余り深刻に考えていませんでしたが。

そんなわけで、アプリのライブラリ関係はiSCSIに。

ただのファイル

そして特に問題の出ない、ただのファイル置き場はSamba(+vfs_fruit)で。

ただね、4.10はまぁ問題なく動いてますが、4.11入れるとmacOSからのフォルダ単位のコピーが失敗したりとか。

具体的にはコピー終わってもフォルダが半透明表示のまま開けない。何かのメタデータ更新失敗している臭い？

追っかけるの面倒だったので、さっくり4.10に戻しました。

どうもこちらも予断を許さない模様。

TimeMachine

巷では「Sambaで置換え可」なんて言われてますが…、

初回作成はSambaから出来ないとか。（2回目以降はSambaからOK）
同じくハマりました。

FreeBSD限定かもしれませんが、ちょっと怖くてTimeMachineをSambaに移行出来ませんでした。

---

そんなわけでだいぶNetatalk依存減らせましたが、まだまだ全廃には至らず。

う〜ん。