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イニシエーター
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依存減らせましたが、まだまだ全廃には至らず。
う〜ん。
