Re: [9fans] P9p's mount(1) on linux
On Fri, Jun 20, 2008 at 6:04 AM, Eric Van Hensbergen [EMAIL PROTECTED] wrote: It'd be nice to have something which supported the virtio transport It would be nice if 9mount and/or 9bind could do an unshare to create a new namespace, Some support for the loose cache would be nice, and I don't see any way of setting larger (or smaller) msize. Options reflecting Lucho's access option should also be incorporated to give users some flexibility there. rename the executable to match the mount helper format (mount.9p) and install it in /sbin. I need to familiarise myself with these options and the mount helper framework before I can sensibly support them. Is there any relevant documentation I should be aware of aside from /usr/src/linux/Documentation/filesystems/9p.txt? Won't happen immediately though, this weekend is free TF2 weekend and wine 1.0 was just released :) -sqweek
Re: [9fans] P9p's mount(1) on linux
On Thu, Jun 19, 2008 at 4:04 PM, Eric Van Hensbergen [EMAIL PROTECTED] wrote: Lucho had a mount helper at one time that was able to use p9p to authenticate when necessary -- this would be a nice feature to include in the mount helper but is difficult to include without p9p as a dependency. It would be nice if 9mount and/or 9bind could do an unshare to create a new namespace, but given the current Linux semantics, I'm not sure you can get the right behavior (ie. 9mount will have its own name space, but then the mount won't be visible in the shell which called it). yes, the way we fixed this on 2.6.24 and clusters was that the mount helper actually forked a shell for you as well. So you specified your entire name space, the mount helper forked with NEWNS, and at the end it dropped you into a shell. Not really very intuitive, but it worked really well. thanks ron
Re: [9fans] P9p's mount(1) on linux
because I'm difficult you may need to [...] -eric Amen.
Re: [9fans] P9p's mount(1) on linux
Thanks for the patch, Uriel. The http://swtch.com/v9fs script stopped working a long time ago, and I never bothered to find out why. I've changed the text on that page, though clicking on the date and checksums link has always shown that the last update was October 2006. A few p9p programs--acme, tapefs, vacfs--now accept a -m option directing them to mount at a particular place in the directory tree, via 9pfuse. There is no option to mount via the Linux 9p module. I'm a little tired of the Fuse sucks meme. The fuse libraries are not so great, but the fuse kernel interface is completely reasonable, and arguably a better fit for Unix than 9P is. A lot of the hard work and churn in Eric's code is because he's trying to do a good translation from 9P to Unix VFS. Fuse lets the individual file servers take care of that, which is fine with me. Also, the FUSE kernel interface, in my experience, has been a bit more solid and certainly changes less often. I think that Fuse gets a bad rap mainly because the people using it to write file servers don't do a good job. I've never run into bugs in the fuse kernel driver itself. User-level file servers are an entirely new concept for most people (present company excluded), so it's not surprising that most of the people out there writing user-level file servers don't fully understand the issues in what they're implementing. But the Fuse kernel developers do. I wrote a new user-level file server a month ago, something I hadn't done in years, and I did it on Linux, using lib9p backed by 9pfuse. It was an entirely pleasant experience. Russ
Re: [9fans] P9p's mount(1) on linux
By the way, where can one find the git tree with the latest v9fs? I was googling and struggling with the swik 'thing' (words fail me...), but couldn't find it, I know it is somewhere... The latest is in linus' head branch on kernel.org. being unfamilar with this jargon, i initially misread this as commentary rather than fact. ☺ - erik
Re: [9fans] P9p's mount(1) on linux
On Thu, Jun 19, 2008 at 5:10 PM, Russ Cox [EMAIL PROTECTED] wrote: Thanks for the patch, Uriel. The http://swtch.com/v9fs script stopped working a long time ago, and I never bothered to find out why. I've changed the text on that page, though clicking on the date and checksums link has always shown that the last update was October 2006. A few p9p programs--acme, tapefs, vacfs--now accept a -m option directing them to mount at a particular place in the directory tree, via 9pfuse. There is no option to mount via the Linux 9p module. Why not have them use p9p's mount(1)? I wont say anything about the whole fuse debacl^h^hte, I don't think it is productive, but in any case it would be nice if p9p still allowed people to take advantage of v9fs when available, one of the reasons v9fs has sucked so much in the paste is that it basically had zero users and underwent zero testing. Peace and best wishes. uriel
Re: [9fans] P9p's mount(1) on linux
On Thu, Jun 19, 2008 at 11:53 PM, Eric Van Hensbergen [EMAIL PROTECTED] wrote: Whatever function deals with passing the options to the mount system call needs the modification. The few changes that are there may be fixed by me doing a better job and supporting old names for options, but it won't help for the kernels already in circulation. I've just updated to 2.6.25 which means I finally had to fix 9mount to work with the = 2.6.24 mount options. Dealt with backwards compatibility by simply adding both the pre AND post 2.6.24 mount options (which was suggested by uriel or jyujin on IRC awhile back). So, mounting works, but v9fs's option string appears to be screwed, which I was relying on for 9umount (to prevent unmounting things mounted by other users). Which is not the best plan, but I'm not sure how else to do it... Basically it will probably be best to structure it as a mount helper and ship it in its own package. I'm not sure how mount helpers work... would you have to be root to use it that way? -sqweek
Re: [9fans] P9p's mount(1) on linux
On Thu, Jun 19, 2008 at 11:10 PM, Russ Cox [EMAIL PROTECTED] wrote: I wrote a new user-level file server a month ago, something I hadn't done in years, and I did it on Linux, using lib9p backed by 9pfuse. It was an entirely pleasant experience. Speaking of 9pfuse - I've just pulled and the version distributed with p9p is still not going to work on linux/x86_64. I posted a patch for this[1], though 9fans.net doesn't appear to archive attachments - see http://sqweek.dnsdojo.org/tmp/9pfuse.LARGEFILE.diff Also, I've sent you a couple of emails off-list recently about a bug in 9p(1). I can't think of anything I might have done to offend you, so I'm assuming they've been marked as spam or otherwise waylaid - should I just post the patch to 9fans? If you did get the patch and have just been thinking about it, then my apologies for being impatient. That scenario just seems increasingly unlikely :) [1] http://9fans.net/archive/2008/03/530 -sqweek
Re: [9fans] P9p's mount(1) on linux
Also any other feedback on what changes and improvements 9mount might need before it can be made part of p9p (or maybe shipped with the standard linux mount(1) tools?). I'll take a look today so I'm up to date on the current station and let you know. Basically it will probably be best to structure it as a mount helper and ship it in its own package. IIRC all the other mount helpers (with the possible exception of NFS) ship independently. It looks like a really good start. It'd be nice to have something which supported the virtio transport as well as there is going to be an influx of those users shortly. Lucho had a mount helper at one time that was able to use p9p to authenticate when necessary -- this would be a nice feature to include in the mount helper but is difficult to include without p9p as a dependency. It would be nice if 9mount and/or 9bind could do an unshare to create a new namespace, but given the current Linux semantics, I'm not sure you can get the right behavior (ie. 9mount will have its own name space, but then the mount won't be visible in the shell which called it). Some support for the loose cache would be nice, and I don't see any way of setting larger (or smaller) msize. Options reflecting Lucho's access option should also be incorporated to give users some flexibility there. Most of these are enhancements that shouldn't stand in the way of a packaging and submission to the distros The only thing you need to do for them is rename the executable to match the mount helper format (mount.9p) and install it in /sbin. Not sure if there are any other requirements for mount helpers, but easy enough to test ;) If you need additional examples look at mount.cifs or mount.fuse -- looks like cifs has a umount helper as well -eric
Re: [9fans] P9p's mount(1) on linux
Fuse on the Mac is markedly inferior. -rob
Re: [9fans] P9p's mount(1) on linux
Speaking of 9pfuse - I've just pulled and the version distributed with p9p is still not going to work on linux/x86_64. I posted a patch for this[1], though 9fans.net doesn't appear to archive attachments - see http://sqweek.dnsdojo.org/tmp/9pfuse.LARGEFILE.diff Done. Also, I've sent you a couple of emails off-list recently about a bug in 9p(1). I can't think of anything I might have done to offend you, so I'm assuming they've been marked as spam or otherwise waylaid - should I just post the patch to 9fans? If you did get the patch and have just been thinking about it, then my apologies for being impatient. That scenario just seems increasingly unlikely :) Done. The patch you sent had to do with Unix signals, so I had been putting off having to think about it. Russ
Re: [9fans] P9p's mount(1) on linux
On Thu, Jun 19, 2008 at 6:21 PM, Russ Cox [EMAIL PROTECTED] wrote: A few p9p programs--acme, tapefs, vacfs--now accept a -m option directing them to mount at a particular place in the directory tree, via 9pfuse. There is no option to mount via the Linux 9p module. Why not have them use p9p's mount(1)? The code is trying to mount a file descriptor, and the Linux 9P module provides no way to do that. (In fact, that was the very first thing I asked for, years ago, when I started trying to use v9fs, and to my knowledge, it still hasn't happened. Ron and Eric are focused on replacing NFS, not building user-level file servers.) The ability to mount file descriptors has been in for a few years (at least since 2006). trans=fd allows you to mount from a file descriptor (or from separate read and write file descriptors). The code should be functional, but it is not something which currently gets regressed very often. -eric I edited the code to call out to a non-existent mount9p program before it invokes 9pfuse. If you put a mount9p in your path that can be invoked: mount9p - /mnt to mount fd 0 onto /mnt, then the -m options will use that instead of 9pfuse. Perhaps one day v9fs will ship with such a program. Russ
Re: [9fans] P9p's mount(1) on linux
The ability to mount file descriptors has been in for a few years (at least since 2006). trans=fd allows you to mount from a file descriptor (or from separate read and write file descriptors). The code should be functional, but it is not something which currently gets regressed very often. yep. rangboom agent uses v9fs this way for the imported shared ns: opts = smprint(noextend,%smsize=%d,name=%s,proto=fd,rfdno=%d,wfdno=%d, (ifsdebug?debug=0x7,:), 8*1024, getenv(USER), so[1], so[1]);
Re: [9fans] P9p's mount(1) on linux
On Fri, Jun 20, 2008 at 6:59 AM, Russ Cox [EMAIL PROTECTED] wrote: Also, I've sent you a couple of emails off-list recently about a bug in 9p(1). I can't think of anything I might have done to offend you, so I'm assuming they've been marked as spam or otherwise waylaid - should I just post the patch to 9fans? If you did get the patch and have just been thinking about it, then my apologies for being impatient. That scenario just seems increasingly unlikely :) Done. The patch you sent had to do with Unix signals, so I had been putting off having to think about it. Hah, fair enough! Thanks, but I shouldn't have rushed you - the modified patch doesn't work. writen() never returns anything less than 0. I don't really follow its purpose either - at first I thought it was there to account for an interrupted syscall, but the implementation differs from what I would expect for that. -sqweek
Re: [9fans] P9p's mount(1) on linux
Thanks for your reply, but I'm not clear what you mean: should p9p's
mount check the kernel version? or are you talking about 9mount?
By the way, where can one find the git tree with the latest v9fs? I
was googling and struggling with the swik 'thing' (words fail me...),
but couldn't find it, I know it is somewhere...
Also any other feedback on what changes and improvements 9mount might
need before it can be made part of p9p (or maybe shipped with the
standard linux mount(1) tools?).
uriel
On Thu, Jun 19, 2008 at 3:57 AM, Eric Van Hensbergen [EMAIL PROTECTED] wrote:
because I'm difficult you may need to check the version of the kernel
you are running, some of the options syntax has changed and you may
want to set some of the newer security options (the access option) to
be more consistent with the Plan 9 mindset.
-eric
On Wed, Jun 18, 2008 at 8:42 PM, Uriel [EMAIL PROTECTED] wrote:
Here is a tinny patch to make p9p's mount(1) work on linux even if you
have the v9fs (or fuse *yuck*) modules built into your kernel rather
than as modules.
Still there is the issue of what to do if you are not root, maybe a
9pmount helper program that is suid could take care of this? Sqweek
wrote a very nice 9mount program (
http://sqweek.dnsdojo.org/code/9mount/docs ) that maybe could be
added to p9p, unfortunately v9fs has changed its interface/params once
more and 9mount doesn't work with recent kernels *sigh*
Peace and best wishes
uriel
P.S.: Can someone please forward this to russ, last I heard he had my
email address in his kilfile.
diff -r fe7a4a762f75 bin/mount
--- a/bin/mount Sun Jun 15 01:46:23 2008 -0400
+++ b/bin/mount Thu Jun 19 03:41:08 2008 +0200
@@ -6,12 +6,12 @@
}
switch(`{uname}){
case Linux
- if(lsmod|9 grep -si '^9p(2000)? '){
+ if(cat /proc/filesystems|9 grep -si ' 9p(2000)?$'){
if(u test -S $1)
exec u mount -t 9p -o proto'='unix,name'='$USER $1 $2
exec u mount -t 9p -o proto'='tcp,name'='$USER $1 $2
}
- if(lsmod|9 grep -si '^fuse ')
+ if(cat /proc/filesystems|9 grep -si ' fuse$')
exec 9pfuse $1 $2
echo 'don''t know how to mount (no 9p, no fuse)' [1=2]
case FreeBSD
