Re: [9fans] v9fs release

Re: [9fans] v9fs release

[Geoff Collyer]

Not to be confused with /bin/fs/v10fs nor /bin/fs/v6fs.

Re: [9fans] v9fs release

[Ronald G. Minnich]

ok, Al, thanks for the help and we can take this off-line. See you in
email :-)

curmudgeon@lanl.gov :-)

p.s. or as Jim Choate would call me, "kettle" :-)

Re: [9fans] v9fs release

[Alexander Viro]

On Thu, 28 Nov 2002, Ronald G. Minnich wrote:

> On Thu, 28 Nov 2002, Alexander Viro wrote:
>
> > Frankly, after the look through the source...  Folks, it's unmergable.
> > There are 4 or 5 unrelated patches trying to get out of that beast and
> > as it is the combination will be vetoed.
>
> well, Al, send me your comments. Although as Greg pointed out a merge into

Will do.

> the base is not at the top of our list right now, as we still have much
> work to do.

Hrm.  Less monolitic patchset == less PITA porting it to newer kernel, but
it's your arse, after all...

> If, however, you think we can beat it into mergeable shape with some help
> from you, then I'm willing to look at it. If the goal here is just to let
> you feel better by making gratuitous nasty jabs at people who are just
> trying to contribute something to the community, then I'm less interested.
> It's your call.

OK, let me put it that way: there are several mostly independent things mixed
in there.  Some of them are definitely worth getting them into mergable shape.
Some look like special cases of more generic stuff that would be interesting.
Interesting for merge, that is.

I can help with splitting and cleaning the things up and I'm definitely
interested in seeing some of that stuff (or equivalents) in the tree.
As for the nasty jabs and feeling good...  I've been dealing with ugly
code almost all the time lately (believe me, you don't want to know) and
nothing associated with that makes me feel good.

BTW, if something of that stuff is going into the tree, it will have to
be posted for review anyway (fsdevel/l-k).  For now keeping it to private
mail probably makes sense, though...

Re: [9fans] v9fs release

[matt]

From: "Jim Choate" <ravage@einstein.ssz.com>

> > It's your call.
>
> Pot...Kettle...

s/Jim Choate/Jiminy Cricket/?

Re: [9fans] v9fs release

[Jim Choate]

On Thu, 28 Nov 2002, Ronald G. Minnich wrote:

> from you, then I'm willing to look at it. If the goal here is just to let
> you feel better by making gratuitous nasty jabs at people who are just
> trying to contribute something to the community, then I'm less interested.
> It's your call.

Pot...Kettle...


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] v9fs release

[Ronald G. Minnich]

On Thu, 28 Nov 2002, Alexander Viro wrote:

> Frankly, after the look through the source...  Folks, it's unmergable.
> There are 4 or 5 unrelated patches trying to get out of that beast and
> as it is the combination will be vetoed.

well, Al, send me your comments. Although as Greg pointed out a merge into
the base is not at the top of our list right now, as we still have much
work to do.

If, however, you think we can beat it into mergeable shape with some help
from you, then I'm willing to look at it. If the goal here is just to let
you feel better by making gratuitous nasty jabs at people who are just
trying to contribute something to the community, then I'm less interested.
It's your call.

> I can post detailed review either on fsdevel or here tomorrow (probably
> the former - code and design review of that stuff doesn't look on-topic for
> 9fans).  And no, it won't be pleasant - aside of very sloppy programming in
> a lot of places, there are outright races aplenty.

Let's keep it simple. You send me the comments. We'll apply the ones that
make sense. I'm not quite sure of the value of echoing the level of
comments you just made to any list I can think of.

ron

Re: [9fans] v9fs release

[Greg Watson]

Please don't bother. We are not proposing to merge this with any code
base, nor are we looking for a review of the design or code. This is
simply a work-in-progress that we wish to make available to those who
are interested. Constructive feedback is always appreciated.

It is entirely likely that this will morph into something that is of
no interest to the 9p folks, since we are primarily concerned with
developing for our local environment. Expect to see all sorts of
add-ons in the source tree.

Greg

>On Thu, 28 Nov 2002, Greg Watson wrote:
>
>>  ...and we are planning to mount users home directories, etc. using
>>  v9fs. There's an automounter that mounts the filesystems in a private
>>  namespace each time a process is executed on a node. When the process
>>  terminates the filesystems are auto unmounted.
>
>Umm...  Why the devil was that stuff mixed with 9P support, again?  Do one
>thing and do it well and all such...
>
>Frankly, after the look through the source...  Folks, it's unmergable.
>There are 4 or 5 unrelated patches trying to get out of that beast and
>as it is the combination will be vetoed.
>
>And please, please, use the sane coding style.  Either one described in
>Documentation/CodingStyle or the style common in Plan 9 kernel - they
>are close enough.
>
>I can post detailed review either on fsdevel or here tomorrow (probably
>the former - code and design review of that stuff doesn't look on-topic for
>9fans).  And no, it won't be pleasant - aside of very sloppy programming in
>a lot of places, there are outright races aplenty.
>
>/me sadly shakes head and ponders adding "Required reading: K&P" into the
>place where required versions of cc/binutils/etc. are described...

Re: [9fans] v9fs release

[Alexander Viro]

On Thu, 28 Nov 2002, Greg Watson wrote:

> ...and we are planning to mount users home directories, etc. using
> v9fs. There's an automounter that mounts the filesystems in a private
> namespace each time a process is executed on a node. When the process
> terminates the filesystems are auto unmounted.

Umm...  Why the devil was that stuff mixed with 9P support, again?  Do one
thing and do it well and all such...

Frankly, after the look through the source...  Folks, it's unmergable.
There are 4 or 5 unrelated patches trying to get out of that beast and
as it is the combination will be vetoed.

And please, please, use the sane coding style.  Either one described in
Documentation/CodingStyle or the style common in Plan 9 kernel - they
are close enough.

I can post detailed review either on fsdevel or here tomorrow (probably
the former - code and design review of that stuff doesn't look on-topic for
9fans).  And no, it won't be pleasant - aside of very sloppy programming in
a lot of places, there are outright races aplenty.

/me sadly shakes head and ponders adding "Required reading: K&P" into the
place where required versions of cc/binutils/etc. are described...

Re: [9fans] v9fs release

[Greg Watson]

At 9:50 AM -0700 11/28/02, Ronald G. Minnich wrote:
>On Thu, 28 Nov 2002, Russ Cox wrote:
>
>>  > yup. But our 1024-node cluster has one (1) disk. And no NFS roots or other
>>  > bad ideas :-) So you can nuke that local disk. Can you do that for
>>  > desktops? I think so.
>>
>>  how's it mounted?
>
>it's not. / is a ramdisk. For more details see www.clustermatic.org (all
>you US East Coast guys remember the Vege-Matic, right?)

...and we are planning to mount users home directories, etc. using
v9fs. There's an automounter that mounts the filesystems in a private
namespace each time a process is executed on a node. When the process
terminates the filesystems are auto unmounted.

Greg

Re: [9fans] v9fs release

[Ronald G. Minnich]

On Thu, 28 Nov 2002, Russ Cox wrote:

> > yup. But our 1024-node cluster has one (1) disk. And no NFS roots or other
> > bad ideas :-) So you can nuke that local disk. Can you do that for
> > desktops? I think so.
>
> how's it mounted?

it's not. / is a ramdisk. For more details see www.clustermatic.org (all
you US East Coast guys remember the Vege-Matic, right?)

ron

Re: [9fans] v9fs release

[Russ Cox]

> yup. But our 1024-node cluster has one (1) disk. And no NFS roots or other
> bad ideas :-) So you can nuke that local disk. Can you do that for
> desktops? I think so.

how's it mounted?

Re: [9fans] v9fs release

[Ronald G. Minnich]

On Thu, 28 Nov 2002 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> As a Linux user, I'm interested in your 9p port.   However, when I compare
> Linux and Plan 9, the most scared thing of Linux to me is that I must
> have large local disk for local Linux OS for every desktop machines.

yup. But our 1024-node cluster has one (1) disk. And no NFS roots or other
bad ideas :-) So you can nuke that local disk. Can you do that for
desktops? I think so.

> Anyway, if v9fs can replace NFS, it's nice to us, Linux users.

There are some tricky problems however, but we're working them.
9p is definitely not NFS ... that is good but makes life "interesting".

> Kenji   -- Am I hitting you?

no, you are saying stuff I agree with :-)

ron

Re: [9fans] v9fs release

[okamoto]

> hmm, I have been avoiding talking about v9fs since it is l*nux and I don't
> want anybody on this list to hit me :-) Oh well here goes.

As a Linux user, I'm interested in your 9p port.   However, when I compare
Linux and Plan 9, the most scared thing of Linux to me is that I must
have large local disk for local Linux OS for every desktop machines.
To maintain those large amount of desktops makes me mad.

Anyway, if v9fs can replace NFS, it's nice to us, Linux users.

Kenji   -- Am I hitting you?

Re: [9fans] v9fs release

[Ronald G. Minnich]

On 27 Nov 2002, Keith Nash wrote:

> I happened to be looking at the v9fs site:
> http://sourceforge.net/projects/v9fs/ and I noticed that Ron Minnich and
> Greg Watson have just uploaded a 1.0 release.
>
> v9fs aims to implement 9P on UNIX-like systems.  Currently only Linux
> with the 2.4.19 kernel is supported.

Actually earlier kernels are supported but the improvements on 2.4.19 are
so significant that you want to switch to 2.4.19.

Also we've dumped all the old 2.0 and 2.2 support.

hmm, I have been avoiding talking about v9fs since it is l*nux and I don't
want anybody on this list to hit me :-) Oh well here goes.

I would actually way we've got 9p -- 3e anyway. Then those 9p guys went
and improved 9p so we can't say we're current. Progress is tough. We like
9p2000 so much we plan to make the shift in a bit.

OK, a few new notes.

First, we exploit the private mount stuff in linux to get private name
spaces that are inherited, private, etc.. That program is included in the
distribution (it's called rf). We can also mount through pretty much
arbitrary file descriptors, including pipes. The older stuff assumed
sockets, the newer stuff doesn't, inspired by some ideas Eric Grosse
passed on when he was out here.

Which means that if I am at a conference, on 802.11, am bored to tears by
the talk, and want my home directory, I do something like this:

 ~/src/v9fs//utils//v9fs_mountpipe /remotehome/rminnich /home/rminnich \
'ssh portal.lanl.gov ssh rminnich@xed src/v9fs/servers/ufs/p9server -s'

which means:
mount onto local directory /remotehome/rminnich, from /home/rminnich on
the remote machine, using the command 'ssh blah blah'. The ssh goes to our
gateway box, then we ssh into the real thing, start the server with the -s
switch which means 'assume stdin/out are pipes'. So server talks over that
nice ssh socket. No tunneling, I don't like the idea of leaving these open
sockets around: the data is direct via ssh, and of course encrypted etc.

The short story is that I can get secure (as ssh anyway), private name
spaces on my laptop. This works pretty well, although some things are
still not as fast as I'd like (file I/O is fast, directory listing for
some reason is slow).

GridFTP is dead.

The other thing we have is mobile name spaces on our bproc clusters. All
that means is you do something like this:
# get a clean empty private name space
rf
# now build in a mount
v9fs_mount /localdir /remotedir servername port
# now run somewhere
bpsh 0-9 /bin/somecommand

On each of those 10 nodes /localdir will be a private name space mount you
can get to. Even works as your cwd, so we can get homedirs for people who
care without resorting to NFS (A Very Good Thing; NFS sucks). It's not
'cpu', but we're getting there.

So, if interested, take a look. Andrey can tell you about all the bugs :-)

9p2000 is in the works as are some other things Russ Cox told us to do :-)

ron

[9fans] v9fs release

[Keith Nash]

I happened to be looking at the v9fs site:
http://sourceforge.net/projects/v9fs/
and I noticed that Ron Minnich and Greg Watson have just uploaded a 1.0 release.

v9fs aims to implement 9P on UNIX-like systems.  Currently only Linux with the 2.4.19 kernel is supported.