[9fans] 9pfuse on mac os x

[9fans] 9pfuse on mac os x

[Skip Tavakkolian]

is anyone able to use 9pfuse on mac os x 10.4 (macfuse 1.5.0)?

in my case,  after dial succeeds and mount_fusefs is done,
9pfuse gets stuck waiting to read from fuse device.  i've verified
that macfuse is working with sshfs.  maybe the handshake has changed?

Re: [9fans] 9pfuse on mac os x

[jas]

On May 14, 6:26 pm, 9...@9netics.com (Skip Tavakkolian) wrote:
> is anyone able to use 9pfuse on mac os x 10.4 (macfuse 1.5.0)?

Earlier builds did work on OS X 10.4, I sure hope the macfuse team
didn't move things around yet again...  Though to be honest, the
choice used for default locations on OS X 10.5 finally makes sense.

A warning: MacFuse is very slow on network mount points.

-jas

Re: [9fans] 9pfuse on mac os x

[Fco. J. Ballesteros]

An alternative to use fuse with network
mount points  is to use the o/dav server running on inferno
(this server is now part of the octopus distrib).

I've tested it with the finder several silly programs and it seems to work fine,
although we still consider it alpha (i.e. USE WITH CARE).

Also, faster interaction may be achieved by running o/dav to export
a namespace imported using Op via o/ofs. This saves many rpcs.

>  From: jeff.sickel@gmail.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Fri May 16 10:36:54 CET 2008
>  Subject: Re: [9fans] 9pfuse on mac os x
>
>  On May 14, 6:26 pm, 9...@9netics.com (Skip Tavakkolian) wrote:
>  > is anyone able to use 9pfuse on mac os x 10.4 (macfuse 1.5.0)?
>
>  Earlier builds did work on OS X 10.4, I sure hope the macfuse team
>  didn't move things around yet again... Though to be honest, the
>  choice used for default locations on OS X 10.5 finally makes sense.
>
>  A warning: MacFuse is very slow on network mount points.
>
>  -jas

Re: [9fans] 9pfuse on mac os x

[a]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

// I sure hope the macfuse team didn't move things around yet again.

Oh, you'd like that, wouldn't you? If things just stayed where they were
so you could find them when you wanted them? Sheesh. We listen to
guys like you and we'll end up with all the fun taken out of computing.

: vav; ls -ld /System/Library/Extensions/fusefs.kext
ls: /System/Library/Extensions/fusefs.kext: No such file or directory
: vav; ls -ld /Library/Filesystems/fusefs.fs/Support/fusefs.kext
drwxr-xr-x  3 root  wheel  102 Mar 31 15:44 /Library/Filesystems/fusefs.fs/Support/fusefs.kext

Also, the sysctl bit in /9/bin/mount no longer turns up anything useful;
it needs to look for macfuse.version rather than fuse.version.

That said, I agree the new locations do make more sense, and having
made the changes locally, 9pfuse and mount work for me. This box
doesn't have the versions versions in question, though; I'll have my
10.4 box this afternoon.
Anthony

[-- Attachment #2: Type: message/rfc822, Size: 2228 bytes --]

From: jas <jeff.sickel@gmail.com>
To: 9fans@9fans.net
Subject: Re: [9fans] 9pfuse on mac os x
Date: Fri, 16 May 2008 08:28:49 GMT
Message-ID: <e9369615-4038-4338-b71c-f5f76bdac3e1@r66g2000hsg.googlegroups.com>

On May 14, 6:26 pm, 9...@9netics.com (Skip Tavakkolian) wrote:
> is anyone able to use 9pfuse on mac os x 10.4 (macfuse 1.5.0)?

Earlier builds did work on OS X 10.4, I sure hope the macfuse team
didn't move things around yet again...  Though to be honest, the
choice used for default locations on OS X 10.5 finally makes sense.

A warning: MacFuse is very slow on network mount points.

-jas

Re: [9fans] 9pfuse on mac os x

[Skip Tavakkolian]

it's a little deeper; i'm wading in the mire that is libfuse to see if
i can spot the difference from what 9pfuse has. i'm hoping some
combination of '-o's to mount_fusefs will fix it.

about path changes, 9pfuse cleverly checks and remembers the right one
when access() succeeds. 9pfuse exec's mount_fusefs, which then forks,
but waiting on something.  i didn't see any references to fuse.version
in p9p source. what file?

On Fri, May 16, 2008 at 6:21 AM,  <a@9srv.net> wrote:
> : vav; ls -ld /System/Library/Extensions/fusefs.kext
> ls: /System/Library/Extensions/fusefs.kext: No such file or directory
> : vav; ls -ld /Library/Filesystems/fusefs.fs/Support/fusefs.kext
> drwxr-xr-x  3 root  wheel  102 Mar 31 15:44 /Library/Filesystems/fusefs.fs/Support/fusefs.kext
>
> Also, the sysctl bit in /9/bin/mount no longer turns up anything useful;
> it needs to look for macfuse.version rather than fuse.version.
>

Re: [9fans] 9pfuse on mac os x

[a]

// i didn't see any references to fuse.version
// in p9p source. what file?

$PLAN9/bin/mount does a 'sysctl fuse.version' to see if it's
already loaded, and looks for the kext explicitly (and as of
v1.3, in the wrong place).

not part of 9pfuse, but support staff.
a

Re: [9fans] 9pfuse on mac os x

[Jeff Sickel]

On May 16, 2008, at 12:42 PM, Skip Tavakkolian wrote:

> it's a little deeper; i'm wading in the mire that is libfuse to see if
> i can spot the difference from what 9pfuse has. i'm hoping some
> combination of '-o's to mount_fusefs will fix it.

Sadly it's not the mount_fusefs that's failing.  I've finally gotten
around to looking at this again now that there's a nice new utility
from Russ that uses 9pfuse.

9pfuse does mount (on Leopard at least) with the latest MacFUSE 1.7
from the goog, and you can watch all the debug details.  Unfortunately
9pfuse ends up having similar problems to sshfs, I/O failures when
traversing the mount point.  For sshfs it appears as if the latest
MacFUSE keeps everything mounted as root -- so even if you try to
force your uid it ignores it and you end up with a file hierarchy you
can't traverse.

I'll keep looking through to see if the API changed a bit more.  There
are MacFUSE filesystems that do work, http://www.friday.com/bbum/2008/01/10/silly-hack-of-the-day-mount-the-obj-c-runtime-as-a-filesystem/
.  That example goes through a different path to initialize the fuse
mount...

-jas

Re: [9fans] 9pfuse on mac os x

[Skip Tavakkolian]

i was able to get Rangboom snsa -- which uses code from Russ' 9pfuse
-- to work with macfuse 1.7 (on os x 10.4.x).  the latest 9pfuse has
the patch sqweek sent for xattr; i wonder if that's the problem?

it's depressing to see that Finder acts as demented as Explorer with
incessant directory traversal.

> On May 16, 2008, at 12:42 PM, Skip Tavakkolian wrote:
>
>> it's a little deeper; i'm wading in the mire that is libfuse to see if
>> i can spot the difference from what 9pfuse has. i'm hoping some
>> combination of '-o's to mount_fusefs will fix it.
>
> Sadly it's not the mount_fusefs that's failing.  I've finally gotten
> around to looking at this again now that there's a nice new utility
> from Russ that uses 9pfuse.
>
> 9pfuse does mount (on Leopard at least) with the latest MacFUSE 1.7
> from the goog, and you can watch all the debug details.  Unfortunately
> 9pfuse ends up having similar problems to sshfs, I/O failures when
> traversing the mount point.  For sshfs it appears as if the latest
> MacFUSE keeps everything mounted as root -- so even if you try to
> force your uid it ignores it and you end up with a file hierarchy you
> can't traverse.
>
> I'll keep looking through to see if the API changed a bit more.  There
> are MacFUSE filesystems that do work, http://www.friday.com/bbum/2008/01/10/silly-hack-of-the-day-mount-the-obj-c-runtime-as-a-filesystem/
> .  That example goes through a different path to initialize the fuse
> mount...
>
> -jas

Re: [9fans] 9pfuse on mac os x

[Jeff Sickel]

On Aug 6, 2008, at 9:31 AM, Skip Tavakkolian wrote:

> i was able to get Rangboom snsa -- which uses code from Russ' 9pfuse
> -- to work with macfuse 1.7 (on os x 10.4.x).  the latest 9pfuse has
> the patch sqweek sent for xattr; i wonder if that's the problem?
>
> it's depressing to see that Finder acts as demented as Explorer with
> incessant directory traversal.

More depressing that sqweek's change works for OS X 10.4.x but not
with the MacFUSE build for 10.5.x.  All I get is:

% 9pfuse -D $ns/plumb /mnt/plumb
...

% cd /mnt/plumb
FUSE -> len 8 unique 0x1 uid 501 gid 501 pid 225 Access nodeid 0x1
mask 0x1
<- Twalk tag 0 fid 0 newfid 1 nwname 0
-> Rwalk tag 0 nwqid 0
<- Topen tag 0 fid 1 mode 0
-> Ropen tag 0 qid (0000000000000000 0 d) iounit 0
<- Tclunk tag 0 fid 1
-> Rclunk tag 0
FUSE <- unique 0x1 (Access)
% ls
FUSE -> len 8 unique 0 uid 501 gid 501 pid 5721 Access nodeid 0x1 mask
0x1
<- Twalk tag 0 fid 0 newfid 1 nwname 0
-> Rwalk tag 0 nwqid 0
<- Topen tag 0 fid 1 mode 0
-> Ropen tag 0 qid (0000000000000000 0 d) iounit 0
<- Tclunk tag 0 fid 1
-> Rclunk tag 0
FUSE <- unique 0 (Access)
FUSE -> len 0 unique 0x3 uid 501 gid 501 pid 5721 Getattr nodeid 0x1
<- Tstat tag 0 fid 0
-> Rstat tag 0  stat '.' 'jas' 'jas' 'jas' q (0000000000000000 0 d) m
020000000500 at 1218033034 mt 1218033034 l 0 t 13312 d 500296
FUSE <- unique 0x3 (Getattr) attr_valid 1 ino 0x8000000000000000 size
0 blocks 0 atime 1218033034 mtime 1218033034 ctime 1218033034 mode
040500 nlink 1 uid 501 gid 501 rdev 0
ls: .: Input/output error



.. back to the drawing board.

-jas

Re: [9fans] 9pfuse on mac os x

[sqweek]

On Wed, Aug 6, 2008 at 10:57 PM, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
> On Aug 6, 2008, at 9:31 AM, Skip Tavakkolian wrote:
>
> More depressing that sqweek's change works for OS X 10.4.x but not with the
> MacFUSE build for 10.5.x.  All I get is:
>
> % ls
...
> FUSE <- unique 0x3 (Getattr) attr_valid 1 ino 0x8000000000000000 size 0
> blocks 0 atime 1218033034 mtime 1218033034 ctime 1218033034 mode 040500
> nlink 1 uid 501 gid 501 rdev 0
> ls: .: Input/output error

 Is this a 32-bit machine? That's a big frigging inode. I don't have a
clue how mac works, but I recently hit a bug with v9fs where a certain
qid path got mapped to an inode of zero and subsequently disappeared
in the linux vfs layer. Though there was no i/o error there.
-sqweek

Re: [9fans] 9pfuse on mac os x

[jas]

The culprit was simply the structure changes in MacFUSE version of
fuse_kernel.h, at least for the Leopard versions that are now
distributed.

I've got a patch that I'm forwarding to Russ and anyone else
interested in the changes.  Not tested on Tiger as I'm no longer
running that version of the OS--that doesn't mean it shouldn't be
supported, just means it will take a bit longer for me to test the
changes there.

-jas