[9fans] mount acme on plan9port
Lorenzo Bolla
Eric Van Hensbergen
> I'm trying to use "9 mount" to mount acme's socket (in `namespace`/acme) to
> some directory in /mnt (let's say /mnt/acme). I'm using ArchLInux:
> $> uname -a
> Linux eee 2.6.32-ARCH #1 SMP PREEMPT Sat Dec 26 08:26:17 UTC 2009 i686
> Intel(R) Atom(TM) CPU N280 @ 1.66GHz GenuineIntel GNU/Linux
> The simple command:
> /tmp/ns.lollo.:0/acme /home/lollo/acme
> and I've traced down the offending option to be "trans=unix".
> Any suggestions?
you shouldn't need -o unix,trans=unix -- just trans=unix.
Double check the 9pnet module is installed as well as the 9p module
(it should be automagically in the kernel version you are running).
Also, a good tip when trying to figure out whats going south when v9fs
is involved is to add debug=0xffff into your mount options and post
the respective sections of your /var/log/messages.
Just tried it on 2.6.33-rc4 and it mounted fine
mount -t 9p /tmp/ns.root.localhost:10/acme /mnt -o trans=unix,uname=root
-eric
Lorenzo Bolla
Russ Cox
It works less well with the 9p module.
Assuming you have write permission on /mnt/acme
and FUSE installed,
acme -m /mnt/acme
should work just fine.
Russ
David Leimbach
Russ Cox
> How about on MacFUSE? I remember there being some issues there. In fact,
> I'm now using an SSHFS that is *not* a FUSE module, but a pretty nicely done
> independent implementation.
The only MacFUSE issues have been using the correct path
since the installed binaries seemed to move around each time
a new version came out. That seems to have settled down.
Russ
Ethan Grammatikidis
Commands may be renamed or missing too. 9pfuse(4) states "The
fusermount binary must exist in the current search path," however the
nearest thing I see to that with macfuse 2.0.2 is:
$ locate -i mount | grep -i fuse
/System/Library/Filesystems/fusefs.fs/Support/mount_fusefs
Running it I get the nice little mesage: "This program is not meant
to be called directly. The MacFUSE library calls it." Lovely.
--
freedesktop.org, because unix doesn't make things harder enough.
Ethan Grammatikidis
eek...@fastmail.fm
Lorenzo Bolla
roger peppe
which creates a new window.
i've thought in the past that perhaps the first write
to a file in mnt/acme/new should create the window,
rather than just walking to it.
it always seems odd to me that du -a /mnt has side effects.
2010/1/27 Lorenzo Bolla <lbo...@gmail.com>:
roger peppe
conventional and necessary in unix.
the 9p fuse converter can't legitimately cache the
qids from the directory read, so there's probably
no other way.
2010/1/27 erik quanstrom <quan...@quanstro.net>:
> On Wed Jan 27 08:42:31 EST 2010, rogp...@gmail.com wrote:
>> i guess that's because it's walking into mnt/acme/new,
>> which creates a new window.
>>
>> i've thought in the past that perhaps the first write
>> to a file in mnt/acme/new should create the window,
>> rather than just walking to it.
>>
>> it always seems odd to me that du -a /mnt has side effects.
>
> seems even more antisocial that fuse is walking
> around for no reason. there's a fine line between
> programs doing things for you and to you.
>
> - erik
>
>
erik quanstrom
> which creates a new window.
>
> i've thought in the past that perhaps the first write
> to a file in mnt/acme/new should create the window,
> rather than just walking to it.
>
> it always seems odd to me that du -a /mnt has side effects.
seems even more antisocial that fuse is walking
Eric Van Hensbergen
problem, fidcreate should just be allocating resources. I'll try and
reproduce and add it to the bug list. There were some latent boofhead
bugs in the option parsing code -- its possible that there's one in
the trans_fd option parsing that is overflowing a buffer and
corrupting memory.
Thanks Again,
-eric
erik quanstrom
> fuse is probably just doing a stat of each file, as is
> conventional and necessary in unix.
>
> the 9p fuse converter can't legitimately cache the
> qids from the directory read, so there's probably
> no other way.
why is it walking there in the first place? i might
be able to understand fuse reading the top level
directory. but new isn't even at the top level.
- erik
Eric Van Hensbergen
interesting experience.
-eric
ron minnich
> reflection of Linux VFS operations into 9P is often a strange and
> interesting experience.
Wish I could find Lucho's email on this, but the Linux guys
particularly don't like things like clone files; "Our scripts will
read them and cause trouble" is the basic complaint.
Bringing some of these new ideas to older OSes will hit some
incompatibilities that can't be fixed ...
ron
Charles Forsyth
unlike reading all those harmless files in /dev with no side-effects whatsoever
Russ Cox
> be able to understand fuse reading the top level
> directory. but new isn't even at the top level.
yes it is. /mnt/acme is the root, hence /mnt/acme/new
is in the top level.
ls -l /mnt/acme
does a directory read to obtain just the names of the
directory entries (that's all the unix interface allows)
and then stats each file in the directory, which turns
into a 9p walk+stat+clunk.
if you ran ls -l /mnt/acme/* in plan 9 you'd get the
same behavior. the difference is that 9p has
optimized the star-free case in a way that unix
cannot take advantage of.
russ
roger peppe
> if you ran ls -l /mnt/acme/* in plan 9 you'd get the
> same behavior. the difference is that 9p has
> optimized the star-free case in a way that unix
> cannot take advantage of.
ls -ld /mnt/acme/* would be a better illustration, i think.