MacFUSE 9P Bridge

FUSE

FUSE とは

Plan9　を除く普通のOSではファイルシステムのコードはカーネルの中に存在し、そのことが新しいファイルシステムをOSに組み込むことを困難(開発が困難なばかりか、OSの配布者以外は事実上配布不可能)にしていた。Plan9 ではファイルシステムのコードをカーネルの外に置き、カーネルにはファイルシステムとのインターフェースに関するコードを置く。この考え方はFUSE(Filesystem in Userspace)として他のOSでも採用されつつある1。

FUSE(Filesystem in Userspace) を使うと、ユーザースペースのプログラムによってファイルシステムを構成できる。このメリットは計り知れない。例えば

• マウントがユーザの権限でできる
  
• ファイルシステムを追加するのにカーネルの再構成が必要ない
  
• ユーザの協力によって様々なファイルシステムを追加できる
  

現在までに FUSE を基にした多様なファイルシステムが作成されているが、僕とっては sshfs が役に立っている。
また僕が作った FUSE のサンプル Maxim があり、MacOS, Linux, FreeBSD で動作が確認されている。
FUSE の面白さが分かるサンプルにしたつもりである。

• Play with Fuse
  http://ar.nyx.link/fuse/index.html
  

FUSE に関する Russ Cox の批評

From: rsc@plan9.bell-labs.com
Subject: [9fans] user-level file systems for Linux
Date: 2004年2月19日 10:57:42:JST
To: 9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu

There is a user-level file system driver for Linux called FUSE that has just released a new stable version:
http://sourceforge.net/forum/forum.php?forum_id=350517
They have user-level servers to mount various archives and various network protocols (http, ftp, smb).

The protocol itself looks fairly similar to the old 9P:
http://tinyurl.com/28f2y

There is another similar project called LUFS
http://lufs.sourceforge.net/lufs/
though it seems more complicated than necessary and makes at least one (imo) critical mistake: no fids.

Actually there have been a handful of projects doing similar things over the past few years, and they've all died out. I'm optimistic about FUSE because it's almost an exact translation of the VFS layer, meaning that it's simple and as expressive as possible.

Russ

MacFUSE (OSXFUSE)

MacFUSE は OS X 10.4 以降で使える。発行元の Google のページには次のように書かれている。

Examples of file systems that work and have been tested (to varying degrees) include sshfs, ntfs-3g (read/write NTFS), ftpfs (read/write FTP), wdfs (WebDAV), cryptofs, encfs, bindfs, unionfs, beaglefs (yes, including the entire Beagle paraphernalia), and so on.
(http://code.google.com/p/macfuse/)

インストール (OSXFUSE)

https://osxfuse.github.io/
からダウンロードすれば良いと思う。"FUSE for macOS" のパッケージが置かれており、最新版は2017年5月時点で 3.5.8 である。パッケージのファイルは osxfuse-3.5.8.dmg である。

このバージョンのネーミングは非常に誤解を招く。FUSE を使ったアプリケーションにとって重要なのはライブラリである。

ライブラリのバージョン選択に関しては以下の点に注意する必要がある。

• FUSE2 (FUSE version 2)
  
• FUSE3 (FUSE version 3)
  

注意すべきは osxfuse-3.5.8.dmg のインストールで生成されるライブラリは FUSE2 である事である。

インストールすると /dev/osxfuse0, /dev/osxfuse1,..., が作成される。

Plan9port の 9PFUSE は FUSE の API(ライブラリ) は使っていないが、FUSE の提供するカーネル拡張とマウンタを使っている。従って FUSE バージョンの影響を受ける。
さらに重要なことは、9PFUSE は現時点では osxfuse.3.x.x の下では動かない。 → 動く様にしました(2017/05/27)

Mac は OS のバージョンアップが激しく、その度にアプケーションは大きな影響を受ける。

動作の確認

(以下の記事は古くなっている可能性がある)

動作確認には SpotlightFS を使うのが簡便であろう。
Gogle のページには次の例が載ってはいるが...

$ mkdir /Volumes/SpotlightFS/Hasselhoff
$ ls -lrt /Volumes/SpotlightFS/Hasselhoff
[... output omitted to avoid embarrassment ...]

-bash$ mkdir /Volumes/SpotlightFS/Google
mkdir: /Volumes/SpotlightFS/Google: Permission denied
-bash$ ls -ld /Volumes/SpotlightFS
dr-x------   2 arisawa  arisawa  0 Aug 20 11:58 /Volumes/SpotlightFS
-bash$ ls -l /Volumes/SpotlightFS
total 0
dr-x------   2 arisawa  arisawa  0 Aug 20 11:58 SmarterFolder
-bash$

chmod も効かない!

-bash$ chmod 700  /Volumes/SpotlightFS
-bash$ ls -ld /Volumes/SpotlightFS
dr-x------   2 arisawa  arisawa  0 Aug 20 12:08 /Volumes/SpotlightFS
-bash$

• Unable to write to spotlight volume
  http://www.mail-archive.com/macfuse-devel@googlegroups.com/msg00202.html
  

正しい SpotlightFS の使い方

(以下の記事は古くなっている可能性がある)

まず SpotlightFS を立ち上げておいて

Finder ⇒ ファイル ⇒ 新規スマートフォルダ

/Volumes/SpotlightFS/

macwiki http://macwiki.sourceforge.jp/wiki/index.php/MacFUSE の説明

SporlightFS を起動すると、「SpotlightFS」というボリュームがマウントされます。このボリューム内にディレクトリを作成すると、作成したディレクトリ名を使って Spotlight の検索がおこなわれ、その結果がディレクトリ中にファイルとして表示されるようになります。

SporlightFS を起動すると、「SpotlightFS」というボリュームがマウントされます。ファインダーから新規スマートフォルダを実行し Spotlight の検索を行い、その結果を「保存済みの検索条件」に名前を付けて保存すると、その名前が「SpotlightFS」に生成されます。

References

• OS X ハッキング!
  http://journal.mycom.co.jp/column/osx/235/index.html
http://journal.mycom.co.jp/column/osx/213/index.html
  
• macfuse
  http://code.google.com/p/macfuse/
  
• Filesystem in Userspace
  http://fuse.sourceforge.net/
  
• MacFUSE
  http://macwiki.sourceforge.jp/wiki/index.php/MacFUSE
  
• The Spotlight File System for MacFUSE
  http://code.google.com/p/macfuse/wiki/MACFUSE_FS_SPOTLIGHTFS
http://code.google.com/p/macfuse/downloads/list
  

Plan9port

インストール

Mac の FUSE を使って Plan 9 のファイルシステムをマウントするには MacFUSE(OSXFUSE) の他に Plan9port が必要である。
Plan9port は PowerPC Mac、intel Mac 共にサポートしている。

Plan9port のコードは以下のサイトに置かれている。(いた)

• http://swtch.com/plan9port/
  
• https://code.google.com/archive/p/plan9port/downloads
  
• https://github.com/9fans/plan9port
  

GITHUB 版の Plan9port のインストールに関しては別ページに解説する。→ http:/p9p/index.html

Plan9port には Plan9 の使いやすいライブラリやコマンドが多数含まれており、特に rc は、unix 系の分かり難くて継ぎ接ぎの貧弱なシェルに比べると天地の違いであり、きっと好きになると思う。なお rc はスクリプト言語に特化しているので、コマンド環境として使うには rlwrap との組み合わせが良いと思う(コマンド履歴が使えるようになる)。

また Linux や FreeBSD のテキストエディタや xterm は貧弱で使いにくい。Plan9port の acme や 9term はきっと作業効率を大幅に高めると思う。

rc については以下の筆者の記事が参考になる。

• http:/rc/index.html
  
• http:/rc/rc2.html
  

9PFUSE

ネットの記事を見ていると FUSE の能力を示すデモとして sshfs が注目されているようだ。確かに sshfs は UNIX ユーザにとっては驚きであろう。しかし僕としてはこのようなまがい物ではなく、リモートファイルシステムとの本物のリンクが欲しい。Plan 9 の 9P2000 は本物だ。

9PFUSE を使う場合にはバグの修正が必要

筆者の実験では

• Linux、MacOS では動く(Bugの修正が必要)
  
• FreeBSD では動かない(試した挙句、give up)
  

Russ の Plan9port には認証に関するバグが含まれている。さらに Mac の場合、リモートホストにアップロードできない問題がある。
必要な修正に関しては、 http:/p9p/ に解説されている。

コマンドでの操作に関しては以上の修正で(現在のところ) Mac、Linux、FreeBSD で実用になっている。

ndb/local

$PLAN9/ndb/localの設定:

# ndb - only used for authdial right now

# database - would add extra file= lines here
# probably need some kind of syntax to avoid hard-coding paths.

database
	file=root-servers

# authentication domains

authdom=outside.plan9.bell-labs.com
	auth=sources.cs.bell-labs.com
authdom=hebe.local

dom=local
	# we need this entry for non Plan9 client
	# the ns value is the name server for dom=local
	ns=hebe.local	# for speed up
	auth=hebe

#
#	--- WARNING ---
#	ipv4 must be first, then ipv6
#	otherwise ndb/ipquery does not work!
#

#	plan9port does not support il protocol
#	look $plan9/src/lib9/_p9dialparse.c
#

ipnet=local ip=192.168.0.0 ipmask=255.255.255.0
	ipgw=192.168.0.1
	proto=tcp
	auth=hebe
	fs=hebe
	dns=io
	# these values are advertised by DHCP or BOOTP. (look dhcpd(8))
	# we assume that dhcpd is running on the same ip. look /cfg/common/cpurc
	# search domains are given by dnsdomain
	# if query is ar, then ar.local and then ar.aichi-u.ac.jp is looked
	# they are not advertised by DHCP server
	# therefore DHCP client should add (if unix):
	#	search local
	#	search aichi-u.ac.jp
	#  are used only for ndb/dnsquery
	dnsdomain=local

sys=router
	dom=router.local
	# the IPs below are LAN side
	# ether=1066820ced19	# WAN
	# ether=1066820ced18	# LAN
	ip=192.168.0.1

sys=hebe
	dom=hebe.local
	ip=192.168.0.6
	# proto=il	# il is not supported in p9p

Plan9 ホスト

9front

Bell-Labs 純正の Plan9 は(チームが Google に移ったために)現在はメンテされていない。ここから派生した OS が2つある。9tom と 9front である。筆者は 9front を推奨する。推奨する理由は、
(a) Cinap の存在である。Cinap の能力は素晴らしく、僕のような凡人100人以上の力を発揮する。多分天才なのだろう。(それでいて謙虚であると言うか、優しくて親切なんだね)
(b) 9front を推奨する他の理由はファイルシステムに Ken Thompson の CWFS が採用されていることにある。こんなことを言うと Fossil のコードを書いた Russ には悪いが、Plan9 の Fossil は回避した方が良い。理由は(Venti との組み合わせで使うために)仕組みが複雑すぎる点にある。Ventiの設定が難しく性能が出にくい。僕が CWFS に移った時点では Fossil にはバグが残っていた。そのバグはまだ残っているかも知れない。Fossil を使う場合には Venti スコアの管理が重要である。このデータを失うと全てを失うことになる。僕が Fossil を使っていた時には、過去10回分のスコアを安全な場所に保管しており、それによって全滅を免れた経験がある¹。
(c) 9front が採用しているブートプロセスが素晴らしい。これは Cinap がいたから出来たのであろう。Plan9 のブートプロセスが抱えている問題点は、Bell-Labs にチームが存在すした時代から問題視されていたが、これが 9front で見事に解決されたわけである。Cinap は Rob Pike, Russ Cox に並ぶ天才である。

CWFS

CWFS(Cached WORM FS) は WORM(Write Once Read Many) と、その cache の組み合わせで動く。この FS(File System) は Ken Thompson の設計とコーディングである。Ken Thompson のものは FS 専用に1つのコンピュータが要求されたが、Geoff によってユーザーランドのファイルシステムとして再設計された。

Plan9 のファイルシステムの最大の特徴は WORM をベースにしていることだろう。どの OS でもファイルは断片に分けて管理されるが、Unix などで採用されている普通のファイルシステムは(メデイアの価格が高価だった時代に設計されたこともあり)断片を再利用する。そのために断片の繋がりを示す情報を失うと致命的な問題を引き起こす。WORM では断片を再利用しない。1度作られた断片は消さないで残す。それによって過去のファイルシステムの履歴を残せるようになった。また断片はデバイスのパーティション上に積み上げ方式で作られていく。ファイルは1日の内で何度も修正されたり、作られたり、消されたりする。そうした1日の中で発生する全ての変化を WORM が直接扱う訳ではない。それらは WORM cache が処理する。 WORM cache は普通のファイルシステムであり cache の中のファイルは必要に応じて1日単位で WORM にダンプ(バックアップ)されると言う仕組みである。

CWFS は僕が全面的に信頼している唯一のファイルシステムである。僕は Plan9 を使うようになってから無停電源装置を入れたことがない。突然の電源OFFの場合に発生するダメッジは高々 cache にしか及ばない。cache が潰れても前日の状態には回復可能である。(業務用はともかく、個人用にはそれで十分である) WORM への書き込みは数分で終わるが、その間に電源 OFF になったらどうか? WORM には正常にダンプされたことを示すマークが積み上げのトップに書き込まれる。ダンプ失敗なら(多分)もう一度ダンプすれば良いだけであろう。推測でしか言えないのは、経験が無いからである。Ken Thompson のことだ、そこまで考えていると思う。

ハードディスクのような機械装置はやがては壊れる。従って結局は WORM のバックアップが欠かせないであろう。実際に僕もバックアップを取っていた。しかし最近はそれも止めた。理由は大容量 SSD が安価に手に入るようになったからである。SSD では可能な上書き回数はハードディスクに比べて少ないので unix などではサーバーには使われないのであるが WORM では上書きが発生しない。コストの面を別にすれば SSD は WORM に最適である。安くなったから僕は WORM のために1TBの SSD を使っている。多分使い切れないであろう。もちろん cache には小容量の SSD を別に割り当てている。

fscons

僕は記憶力が悪く(母によれば僕の子供の頃の病気が原因なのだそうだ) CWFS のコンソールへのアクセス方法が分からなくなるので覚えやすいコマンドを持っている。

fscons:

#!/bin/rc
if(test -e /srv/fscons)
	exec con /srv/fscons
if(test -e /srv/cwfs.cmd)
	exec con -C /srv/cwfs.cmd
echo 'no fscons'
ls /srv

ここで fscons を取り上げるのは、認証問題に関係しているからである。

CWFS は次のオプションを持っている。

• 認証必要/不要
  
• none による接続を認める/認めない
  

noauth

• auth disabled --- 認証不要で接続を認める
  
• auth enabled --- 接続するには認証が必要
  

nonone

• none enabled --- ユーザー none には認証不要で接続を認める (none にはパスワードが与えられていない)
  
• none disabled --- ユーザー none には接続を認めない
  

Plan9 をやっていて感じる難しさは認証に絡む問題である。認証プロセスを外すオプションは、認証以外の部分が正しく働いていることを確認する上で役に立つ。このオプションを使う場合には、もちろん、ルーターなどによって外部からのアクセスを遮断しておく必要がある¹。

認証プロトコル

9front では新しい認証プロトコルが追加された。dp9ik である。これは p9sk1 の代替えである。p9sk1 は現在では古く、インターネットレベルで使用するには危険である。 Plan9port を使って Plan9 ホストに接続するには以下の点に注意を払う必要がある。

• 認証ポートは tcp と il 毎に固定である。il566 及び tcp567
  
• Unix は il をサポートしない。従って Russ の Plan9port も、また drawterm も
  
• ファイルサーバーや CPU サーバーへのアクセスの際に採用される認証サーバは $PLAN9/ndb/local で設定する
  
• Russ の drawterm は dp9ik をサポートしないが、Cinap の drawterm は dp9ik をサポートしている。
  

つまりインターネット環境から家庭などの Plan9 ホストに cpu コマンドなどによるアクセスを許し、かつ p9sk1 を使いたくない場合にはそれ用に認証サーバが必要になると言うことである。僕はそのためにもう一つの認証サーバーとして Raspi を使っている。

9front の標準設定では /rc/bin/service.auth/tcp567 は p9sk1 を禁止している。僕は Unix 環境からのアクセスを必要としているので家庭内ネットワーク用の認証サーバ(ファイルサーバーと兼用)で次のように古いプロトコルも(p9sk1)を許している。

#!/bin/rc
#exec /bin/auth/authsrv -N $3 	# -N disables old des key
exec /bin/auth/authsrv $3

ファイルサーバーの factotum キー:

key proto=p9sk1 dom=local user=arisawa !password=XXXXXX
key proto=dp9ik dom=local user=arisawa !password=XXXXXX
...

マウント

準備 (one time action)

mbook から hebe をマウントするために、以下のディレクトリが mbook に追加されている。

• /n
  
• /srv
  
• /mnt
  

hebe のマウントポイントを作ると仮定して、ユーザー(例えば arisawa)から

sudo mkdir /n /srv /mnt
sudo chown arisawa /n /srv /mnt
chmod 700 /n /srv /mnt
mkdir /mnt/factotum
mkdir /n/hebe

環境変数 NAMESPACE の設定が必要である。

NAMESPACE=/srv ; export NAMESPACE

Plan9port のインストール時に $HOME/.profile に

PLAN9=/usr/local/plan9 export PLAN9
PATH=$PATH:$PLAN9/bin export PATH

/srv には Plan9 ホストとの接続が成功すれば、自動的に /srv/hebe などが生成される。

/mnt は認証エージェント factotum が使う。

接続実験 (認証なし)

初めてトライする人は CWFS を認証なしの設定にし、接続の確認をする。9p コマンドが役に立つ。

9p -a hebe ls

成功したら以下のコマンドを順に実行してみよう。

-bash$ srv hebe
-bash$ ls /srv
hebe
-bash$ 9 mount /srv/hebe /n/hebe
-bash$ ls /n/hebe

/n/hebe へのマウントに成功しているはずである。

接続実験 (認証あり)

サーバーの設定を「認証あり、none お断り」モードにすると Plan9 port の mount は拒否される。この mount は内部で 9pfuse を使っている。既に述べたように、この問題は 9pfuse のバグが原因であり、必要な修正に関しては、
http:/p9p/index.html
に解説されている。

なお、

9 mount /srv/hebe /n/hebe

9pfuse /srv/hebe /n/hebe

Plan9port の 9p コマンドは 9P サーバーとの接続のデバッグにおいて非常に役に立つ。このコマンドの機能は ftp の 9p プロトコル版だと思ってよい。通信状態の基礎が分かるのである。特に認証が正しく働いているか否かの判断が可能である。 9p コマンドは FUSE には関係していない。 Russ の mount のコードは FUSE に強く依存しており、FUSE が抱えている問題点がそのまま Russ の mount に反映される。Russ が FUSE のコードに問題を感じていてもままならない面があるのである。その点で、9p は 100% Russ であり、信頼性は高い。

クリーンな状態から出発すれば上記の通りになるはずだか、しばしは途中からになる。例えば factotum が認証データを得るのは one time action に近い。
他方、1日の内に何回でも　サーバーへの mount や unmount が発生する。そうした場合には発生しがちなエラーを整理する。

Address already in use:

-bash$ srv -a -k 'dom=local' hebe
9pserve: announce unix!/srv/hebe: Address already in use
srv: post9p: 9pserve failed
-bash$ rm /srv/hebe 	# and retry

Address already in use:

-bash$ factotum -a hebe
9pserve: announce unix!/srv/factotum: Address already in use
factotum: post9pservice factotum: 9pserve failed
-bash$

mount point /n/hebe is itself ...:

-bash$ 9 mount /srv/hebe /n/hebe
mount_osxfusefs: mount point /n/hebe is itself on a OSXFUSE volume
-bash$ unmount /n/hebe 	# and retry

Connection refused:

-bash$ 9 mount /srv/hebe /n/hebe
9pfuse: dial /srv/hebe: connect /srv/hebe: Connection refused

診断とクリーンアップ

僕の診断プログラム
http:p9p_chk
http:me
中身を見て、各自の環境に合わせてください。
うまく行かないときのヒントになるかも知れません。

またクリーンアップしてやり直ししたいこともあろう。
http:un9fs
one time action の部分は残している。

9pfs

9pfuse に代わって

ネットを検索していると、9pfs と言うのに出会った[1]。これは Russ の 9pfuse の置き換えを狙っているらしい。こののサイトによると、9pfuse に比べて相当に速いらしい。(キャッシュのお陰だと思う)

Russ は FUSE のライブラリを使用せずに、FUSE のカーネルだけを直接的に利用してコードを書いている。他人の書いたコードに依存したくないのであろう。Russ ほどの力量があればこそ可能な事である。実際に Russ のコードはシンプルで良くわかる。他方 FUSE のライブラリのコードを見ていると、何で... と思う部分が多い。

9pfs の方は FUSE のライブラリを利用している。少々手を加えればコンパイルは成功する¹。

コードの修正

libc.h

 typedef uint32_t u32int;
 typedef int32_t s32int;
 typedef unsigned char uchar;
+typedef unsigned long ulong;
 typedef unsigned long long uvlong;
 typedef long long vlong;

9pfs.c

 		size = CACHECTLSIZE;
 		if(off >= size)
 			return 0;
-		memcpy(buf, "cleared\n" + off, size - off);
+		memcpy(buf, &("cleared\n"[off]), size - off);
 		clearcache(path);
 		return size;

9p.c

つまらない GNU 拡張が使われているために数10行の修正が必要になっている。

問題の部分は

char *calls2str[] = {
  [Tversion]	"Tversion",
  [Tauth]	"Tauth",
  [Tattach]	"Tattach",
  ...

これは clang で蹴られる。この部分は

char *calls2str[] = {
  [Tversion] =	"Tversion",
  [Tauth] =	"Tauth",
  [Tattach] =	"Tattach",
  ...

それにしても GNU は、こんなに詰まらない(酷い)拡張をするのだね~~~
拡張というのは、常に副作用を伴う。従って、拡張が許されるのは相当な理由(合理性)が無くてはならない。例えば、論理的、必然的にあるべき姿が実現していない場合は許されるだろう。しかし、この場合には、文法エラーになって当然の書き方を、1文字の入力の節約のために許してしまおうとする拡張であって、コンパイラのバグと見なして良いものだ。

9pfs.tgz

コードを修正してパッケージにしたものを次に置く。
http:9pfs.tgz

Makefile_osx、Makefile_bsd、Makefile_linux を新たに含めた。
MacOS、FreeBSD、Linux でコンパイルできる事が確認されている。

FreeBSD ではマウントが NG である。(何しろ FUSE が NG)

MacOS と Linux ではマウントは OK。しかし、僕はまだ使い込んでいない。

• 認証によってマウントできるようにすべきだが、その修正はしていない。(この問題は p9p の srv コマンドで解決できる)
  
• Mac はサーバーの残り容量を 0 と判断する。そのためにファイルをアップロードできない。この現象は 9pfuse でも出会ったが、9pfuse の場合にはコードに手を加えアップロードできるようになった。しかし 9pfs ではコードを読んでもその場所が判らない
  

使い方

• Plan9port が必要
  
• factotum のマウントは Plan9port の mount を使う
  
• 環境変数 FACTOTUM が必要 (factotum の位置を指定する)
  
• $PLAN9/ndb/local での認証サーバの設定
  

マウントは 9pfs で統一したいと思っても、factotum とミスマッチがあるらしい。

筆者の環境では

-bash$ factotum -a hebe
-bash$ 9 mount /srv/factotum /mnt/factotum
-bash$ export FACTOTUM=/mnt/factotum
-bash$ 9pfs -a hebe /n/hebe
!adding key: role=client proto=p9sk1 dom=local
user[arisawa]:
password:

ここに

• hebe は筆者のサーバー名
  
• /n/hebe は hebe のマウントポイント
  

あるいは、譜の最後の 9 mount に代わって

9pfs -U /srv/$1 /n/$1

追加コメント

• 9pfs のコードに含まれる環境変数の参照は FACTOTUM のみである。しかし factotum が $PLAN9/ndb/local を参照している。
  
• マウントしたリモートホストのディレクトリに .fscache が生成されたように見えるが、これは見かけ上で、実際にはホスト上には作成されていない。ローカル側に作成される。
  
• ホスト側で変更したファイル名などが 9pfs に反映されないと思った事がある。しかし1分程で反映された。 キャシュの所為で遅れるのだろう。(この問題はキャシュのアルゴリズムに依存している)
  

使ってみて

FUSE API の限界

FUSE では setattr が使えると思っていたが、fuse-2.9.7 のコードを見ている限り、使えるのは FUSE kernel との low level interface みのであって、普通のプログラマが使う API レベルではサポートされていない。

9pfs では API レベルを使っているので setattr がサポートされていない。そのために local のファイルをホスト側にコピーしたときに、元のファイルが持っていた時刻情報(atimeやmatimeなど)まで含めてコピーできない。この事が問題なら 9pfs は使えない事となる。

Russ が 9pfuse で FUSE API を使わなかった理由の1つかも知れない。

その内に解決される可能性は高いのだが...

u9fs がマウントできる

Russ の 9pfuse は unix ホストの u9fs をマウントできないが¹、9pfs だとマウントできる。
もっとも unix から unix ホストのマウントは、現在では sshfs で間に合うだろう。

いろいろな「9pfs」

ところで「9pfs」と言うのはいろいろあるらしい。
記事[1]のコードは Mischief のもの。(コードを見る限り、Mischief は几帳面だね...)
記事[2]から推測すると py9p プロジェクトの副産物としての 9pfs。これは、Saveliev と Mirtchovski による開発である。

前者では

Usage: 9pfs [-anU] [-A aname] [-p port] [-u user] service mtpt

後者では

Usage: 9pfs [-dDw] [-c mode] [-p port] [-r root] [-a address] [user [domain]]

また記事[3]によると、「9pfs」は 9P プロトコルの別名としても使われているらしい。

なお記事[4]には、9P の実装が多数紹介されている。(いつの間にか、こんなに...)

[1] 9pfs
https://github.com/mischief/9pfs

[2] 9pfs man page
https://www.mankier.com/1/9pfs

[3] Xen transport for 9pfs version 1
https://xenbits.xen.org/docs/unstable/misc/9pfs.html

[4] 9P Implementations
http://9p.cat-v.org/implementations

v9fs

/bin/mount -t 9p ....

sudo apt install 9mount

9mount -i hebe /n/hebe

maia$ /bin/mount
...
192.168.0.6 on /n/hebe type 9p (rw,relatime,sync,dirsync,uname=root,access=any,trans=tcp,noextend)
maia$

maia$ ls -l /usr/bin/9*
-rwsr-xr-x 1 root root 14328  9月  5  2018 /usr/bin/9bind
-rwsr-xr-x 1 root root 18584  9月  5  2018 /usr/bin/9mount
-rwsr-xr-x 1 root root 14328  9月  5  2018 /usr/bin/9umount
maia$

srv -a hebe
9mount 'unix!/srv/hebe' /n/hebe

"src" は Plan9port のプログラムである。"srv -a hebe" で hebe と認証付きのコネクションを張ってくれ、接続口を /srv/hebe に作ってくれる。これを 9mount でマウントすればよいとのこと。昔、このことが話題になったことがあったとのことで、次のアドレスを示してくれた。
https://groups.google.com/g/comp.os.plan9/c/0WPz3Iwl3tc?pli=1
実験すると、srv コマンドは factotum を参照するように作られているので使いやすい。(Russ の作だから当然!)

残念ながら macFuse は plan9port の mount とは相性が悪いらしく、不安定である。Linux を経由して我が hebe にマウントすれば気持ちよく使える。Mac においても v9fs がサポートされる日が早く来るのを期待したい。Windows にすら v9fs が組み込まれているらしいから。

追記: macOS でも 9P が正式に使えるようになった[4]。 しかし僕の MacBook は古くて、OS のバージョンアップができない... 僕は20年間も Mac の 9P を追い求めてきたにも関わらずである。
これで OS 分野の Big three が 9P を公式にサポートすることになったのである。従って file service に関しては間違いなく 9P で統一される。現在様々な file service protocol 例えば cifs, nfs, webdav などがまだ使われているが近い将来には全て廃止されるであろう。(2021)

[1] v9fs: Plan 9 Resource Sharing for Linux
https://www.kernel.org/doc/html/latest/filesystems/9p.html

[2] 9mount
http://manpages.ubuntu.com/manpages/jammy/man1/9mount.1.html

[3] Windows 10 WSL: mount creates 9p filesystem instead of drvfs
https://superuser.com/questions/1643551/windows-10-wsl-mount-creates-9p-filesystem-instead-of-drvfs

[4] mount_9p(8) [mojave man page]
https://www.unix.com/man-page/mojave/8/mount_9p

評価

Plan9port の 9pfuse は2つの問題を抱えている:
(1) 認証プロセスをサボっている
(2) サーバーのファイルスペースの残り容量を0にしてしまっている

これらはいずれも簡単に解決できる。( http://p9.nyx.link/p9p/ を見よ)

Linux では 9Pfuse は安定していて文句は無い。Mac では Linux 程安定していない。原因は(多分) 9Pfuse が作られた環境にあるのだろう。FreeBSD では全くダメである。9pfuse どころか FUSE もまともに動かない。

Mac 付属のテキストエディタ TextEdit.app や Xcode.app では、(拡張属性が邪魔をして)編集した結果を保存できない¹。Plan9port の acme は OK である。他に mi.app や atom.app などが問題なく使える。

ところで最近の TextEdit.app は(僕にとっては)非常に使いにくくなっている

• autosave # 何とかならないか? (いろいろトライしたが、どうも手が無い)
  
• xattar # download したテキストファイルを(危ないから)エディタで開けないと言う仕様は馬鹿げている
  

なお僕は edit コマンドを作って持っており、TextEdit.app で読み取る前に xattr を削除することとした。
関係するコードは次の通りである。(rc で書かれている)

xa=`{xattr $e}	# extended attribute
if(~ $xa ?*)
	xattr -d $xa $e
open -a $EDITOR $e || echo $usage

References

• Plan 9 from User Space
  http://swtch.com/plan9port/
  
• 9PCLIENT(3)
  http://swtch.com/plan9port/man/man3/9pclient.html
  
• INTRO(4)
  http://swtch.com/plan9port/man/man4/intro.html
  
• 9PFUSE(4)
  http://swtch.com/plan9port/man/man4/9pfuse.html
  
• FACTOTUM(4)
  http://swtch.com/plan9port/man/man4/factotum.html
  

9PFUSE の古い記事 (参考程度に)

実験環境

クライアントは Mac のノートブック。僕は Mac のノートブックを2つ持っている。PowerBook と MacBook である。いずれも OSX 10.4 環境下で動いている。以下それらを各々 pbook と mbook と呼ぶ。どちらで行っても動作に違いはない。そこで、ここでは pbook での実験のみを示す。

マウントするリモートホストは 3 つを試した。

pc

自宅のデスクトップの Plan 9 端末で、端末と言っても実際にはサーバと同様なサービスを行っている。認証サーバを持たずに、単体で動いている。Factotum と venti を備えている。

ar

大学の Plan 9 の CPU サーバー

pmac

自宅のデスクトップの Mac で u9fs が動いている。

pbook のディレクトリ構成

• X11 は不要
  
• Plan 9 に慣れた者にとって分かりやすい
  

逆にデメリットは、

• マルチユーザ環境で名前の衝突が発生する
  

pc のマウント

実験した日には研究室にある認証サーバ hera は停電のためにダウンしていた。しかし pc は認証サーバーと関係なく動いているので問題はない。

pc に接続するためには、pc の factotum には次の内容が必要である。

key dom=pc proto=p9sk1 user=arisawa !password=xxxxxxxx

以下にマウントに至るまでの pbook で実行するコマンド手順を示す。

-bash$ mkdir /srv   # needs only once
-bash$ mkdir -p /n/pc  # needs only once
-bash$ mkdir -p /mnt/factotum  # needs only once
-bash$ NAMESPACE=/srv
-bash$ export NAMESPACE
-bash$ factotum
# it may be required to execute here (added 2016)
# -bash$ 9 mount /srv/factotum /mnt/factotum
-bash$ 9fs pc

!adding key: role=client proto=p9sk1 dom=pc
user[arisawa]:
password:
!
-bash$ 9 mount /srv/pc /n/pc
kextload: /System/Library/Filesystems/fusefs.fs/Support/fusefs.kext loaded successfully
-bash$ ls /n/pc
386             NOTICE          cfg             lp              rc
68000           acme            cron            mail            sparc
68020           adm             dist            mips            sys
LICENSE         alpha           env             mnt             tmp
LICENSE.afpl    amd64           fd              n               update
LICENSE.gpl     arm             lib             power           usr
-bash$

ディレクトリ /srv と /n/pc はあらかじめ作成しておく。また NAMESPACE の設定と export は .profile で行うのが良いであろう。

9 コマンドは Plan9port のコマンド名が UNIX のコマンド名と衝突する場合に Plan9port のコマンドを実行してくれる。

factotum を実行すると /srv/factotum が生成される。"9fs pc" を実行すると /srv/pc が生成される。/srv に生成されたものはソケットである。

Plan 9 の 9fs はマウントまでやってくれるが、Plan9port の 9fs はやらない。9fs は rc スクリプトで内部で srv を実行している。また、Plan9port の mount も rc スクリプトで、ソースを見るに BSD 系の OS に対しては 9pfuse を実行している。

以下にマウントされた時の Mac の Finder を示す。

Finder に反映された MacFUSE

Factotum の ctl にアクセスする。

-bash$ mkdir -p /mnt/factotum     # needs only onece
-bash$ 9 mount /srv/factotum /mnt/factotum
-bash$ ls /mnt/factotum
confirm conv    ctl     log     needkey proto   rpc
-bash$ cat /mnt/factotum/ctl
key dom=pc proto=p9sk1 role=client user=arisawa !password?
-bash$

factotum にデータを追加するには

echo key 'dom=aichi-u.ac.jp proto=p9sk1 role=client user=arisawa !password=xxxxxxxx' >> /mnt/factotum/ctl

削除するときにも同様である。

問題点

-bash$ ls -l /n/pc
total 85
drwxrwxr-x   1 arisawa  arisawa      0 Jun 27 17:24 386
drwxrwxr-x   1 arisawa  arisawa      0 Jan 31  2007 68000
drwxrwxr-x   1 arisawa  arisawa      0 Jan 31  2007 68020
-r--r--r--   1 arisawa  arisawa  13006 Jul 13  2005 LICENSE
-rw-rw-r--   1 arisawa  arisawa  14333 Jun 29  2003 LICENSE.afpl
-rw-rw-r--   1 arisawa  arisawa  15081 Jun 26  2003 LICENSE.gpl
-r--r--r--   1 arisawa  arisawa     63 Apr 15  2002 NOTICE
drwxrwxr-x   1 arisawa  arisawa      0 Jan 31  2007 acme
...

コマンドでファイルにアクセスする限り、実際にアクセスして拒否されれば知らせてくれる。しかし Mac の Finder を通じてマウスでクリックしていると状況が異なる。Finder は余計な親切をしているのだ。それがあだになって読み取れるはずのファイルが読み取れない事もある。(Finder は正しいメッセージを出していない!)

このような問題は UNIX と Plan 9 と言う異質な OS を結んだから発生したのではない。 UNIX 相互でも管理者ドメインが異なれば同じ問題が発生する。UNIX がネットワーク環境に適合しないと言われる根拠の一つになっている。

参考のために Plan 9 端末から u9fs を使って UNIX (Mac OSX) をマウントした場合の ls -l を示す

--rwxrwxrwx M 29 arisawa staff    6148 Apr 24 22:05 .DS_Store
d-rw------- M 29 root    ???       272 Aug 29 06:34 .Spotlight-V100
d--wx-wx-wx M 29 root    admin     170 Feb 23  2006 .Trashes
[中略]
d-rwxr-xr-x M 29 arisawa staff    1360 Jan 26  2003 システムフォルダ
d-rwxrwxr-x M 29 root    admin     340 Sep 13  2002 書類
d-rwxr-xr-x M 29 arisawa admin      68 Jan 26  2003 起動時に消去する項目

ar のマウント

key dom=aichi-u.ac.jp proto=p9sk1 user=arisawa !password=xxxxxxxx

ar の認証ドメインは aichi-u.ac.jp であるが、factotum には認証サーバーに関する情報が含まれていない。従って pbook から ar をマウントするには ar の認証サーバーが何であるかを知らせる必要がある。この事は $PLAN9/ndb/local で行える。僕のケースでは

authdom=aichi-u.ac.jp
	auth=hera.aichi-u.ac.jp

pmac のマウント

これは unix (like) から unix (like) へのマウントである。

pmac は自宅の PowerMac G4 で、ここでは u9fs が動いている。pmac は Plan 9 端末からはマウントできる。しかし不思議な事に pbook からは(pmac からも)マウントできない。
この問題は現在においても解決できない。9fans ではマウントできるとの情報もある。(2016/02/17)

-bash$ 9fs pmac
authdial: Connection refused

取り消し

mount

9 mount /srv/ar /n/ar

9 unmount /n/ar

9fs

9fs ar

-bash$ ps
  PID  TT  STAT      TIME COMMAND
24157  p1  S      0:00.46 -bash
24276  p1  S      0:00.51 factotum
24278  p1  S      0:02.51 9pserve -u unix!/srv/factotum
24289  p1  S      0:40.18 9pserve -u -M 8192 -A  0 unix!/srv/ar
24306  p1  S      0:11.60 9pserve -u -M 8192 -A  0 unix!/srv/pc
24198  p2  S+     0:00.07 -bash
-bash$ kill 24289
-bash$ ls /srv
ar              factotum        pc
-bash$ rm /srv/ar
-bash$

factotum

-bash$ ps
  PID  TT  STAT      TIME COMMAND
24157  p1  S      0:00.53 -bash
24751  p1  S      0:00.01 factotum
24753  p1  S      0:00.01 9pserve -u unix!/srv/factotum
24198  p2  S+     0:00.07 -bash
-bash$ kill 24751
-bash$ rm /srv/factotum
-bash$

この後に

unmount /mnt/factotum

"9pserve -u unix!/srv/factotum" は factotum によって生成されたプロセスで factotum を落とせば自動的に落ちるが、/srv/factotum は削除しなくてはならない。

診断

実験では 9fs は Plan9port 付属のものをそのまま使用していた。譜を使えは、もっとスムーズに行く可能性がある。

unknown host

bash$ 9fs pc

!adding key: role=client proto=p9sk1 dom=home
user[arisawa]:
password:
!
authdial: unknown host home
bash$

unable to find common key

-bash$ factotum
-bash$ 9fs ar
srv: authproxy: auth_proxy rpc: p9any client ask for keys: unable to find common key
-bash$

Result too large

-bash$ echo key 'dom=aichi-u.ac.jp proto=p9sk1 user=arisawa !password=xxxxxxxx'>/mnt/factotum/ctl
-bash: /mnt/factotum/ctl: Result too large

can't mount on Darwin

-bash$ 9 mount /srv/pc /n/pc
can't mount on Darwin
-bash$

Connection refused (1)

このメッセージはマウントするときに発生する。例えば

-bash$ 9 mount /srv/hebe /n/hebe
9pfuse: dial /srv/hebe: connect /srv/hebe: Connection refused

原因は認証されないままマウントを試みたからだろうと思われる。

参考のために、実行すべきコマンドと、その結果として生成されるファイル("→" で示してある)を以下に示しておく。
"*" はそこに名前が存在することを意味する。また"#" より右はコメントである。

1. factotum # → /srv/factotum
   
2. 9 mount /srv/factotum /mnt/factotum # → /mnt/factotum/*
   
3. 9fs HOST # → /srv/HOST
   
4. 9 mount /srv/HOST /n/HOST # → /n/HOST/*
   

9fs hebe

なお譜だと "9fs HOST" でマウントまで進むはずである。

Connection refused (2)

認証を求めようとして 9fs で次のメッセージに出会うことがある。

-bash$ 9fs nix
authdial: Connection refused

相手ホストは Linux で、こちらは Mac である。
今のところ筆者は unix 相互のマウントに成功したことがない。

fid unknown or out of range

-bash$ 9pfuse /srv/mmac /n/mmac
9pfuse: fsmount: fid unknown or out of range
-bash$

これは macbook から mac mini へのマウントで発生する。もっと一般的に言えば unix (like) から u9fs へのマウントで発生する。原因は認証が正しく行われていないからだろうと思えるが、「Connection refused」との違いが今のところ分からない。

mount point XXX is itself on a OSXFUSE volume

既にマウントされている XXX にさらにマウントしようとした。

unmount XXX