[9fans] implmenting /mnt/9/clone

[9fans] implmenting /mnt/9/clone

[Ronald G. Minnich]

I'm playing around with the p9p ramfs server, and was wondering about the 
best way to implement a file for clone. 

e.g. I have /mnt/9/clone, and when clone is opened, I want to to mean that
/mnt/9/1/ctl is created and fid for that file returned to client, and the
next open of clone gets /mnt/9/2/ctl, etc. As usual, a read of the ctl 
would return the # for that ctl file. 

I can think of a couple of ways to 
do it, with the simplest involving:
- when clone is opened, create #/ctl, e.g. 3/ctl
- swap the qids for clone and the #/ctl file

Any comments on this, or hidden gotchas, or ...

I'm pretty sure this would work for Linux 9p clients, but am not sure 
about the overal cleanliness of this approach, or if there is some better 
way to do it.

ron

Re: [9fans] implmenting /mnt/9/clone

[Eric Van Hensbergen]

On 7/29/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> I'm playing around with the p9p ramfs server, and was wondering about the
> best way to implement a file for clone.
> 
> e.g. I have /mnt/9/clone, and when clone is opened, I want to to mean that
> /mnt/9/1/ctl is created and fid for that file returned to client, and the
> next open of clone gets /mnt/9/2/ctl, etc. As usual, a read of the ctl
> would return the # for that ctl file.
> 

One small problem I've noticed with v9fs and clone style file systems
(in particular ACME) -- make sure things like stat don't trigger the
creation of the resource, otherwise things like ls -l will end up
creating windows, etc.  I haven't found a good way around this from a
Linux perspective.

          -eric

Re: [9fans] implmenting /mnt/9/clone

[Russ Cox]

> I'm playing around with the p9p ramfs server, and was wondering about the
> best way to implement a file for clone.

If you want to build a regular (patterned) synthetic file system,
don't start with the ramfs server, which has a lot of extra baggage
because it must support a general file tree instead of a
regular synthetic one.  In particular, regular file systems
can use regular qids and assign meaning to them.
Cdfs and sshnet are good examples of this on Plan 9.  Look at those.

Russ

Re: [9fans] implmenting /mnt/9/clone

[Ronald G. Minnich]

On Fri, 29 Jul 2005, Eric Van Hensbergen wrote:

> One small problem I've noticed with v9fs and clone style file systems
> (in particular ACME) -- make sure things like stat don't trigger the
> creation of the resource, otherwise things like ls -l will end up
> creating windows, etc.  I haven't found a good way around this from a
> Linux perspective.

interesting. This is due to "negative dentries" I guess? 

ron

Re: [9fans] implmenting /mnt/9/clone

[Eric Van Hensbergen]

On 7/29/05, Ronald G. Minnich <rminnich@lanl.gov> wrote:
> 
> 
> On Fri, 29 Jul 2005, Eric Van Hensbergen wrote:
> 
> > One small problem I've noticed with v9fs and clone style file systems
> > (in particular ACME) -- make sure things like stat don't trigger the
> > creation of the resource, otherwise things like ls -l will end up
> > creating windows, etc.  I haven't found a good way around this from a
> > Linux perspective.
> 
> interesting. This is due to "negative dentries" I guess?
> 

Well, it goes beyond that - Linux is sending getattr for every file
(because it doesn't know it call all the data it needs from the
readdir) so its walking and stating every file.  The only way to get
around this is a temporal cache on the metadata (both dentry and
inode) -- but this could cause problems in other situations (how long
before you invalidate the inode or dentry data?).

I haven't looked into exactly what sets ACME off, but I figure it's
probably keying off the walk.

         -eric

Re: [9fans] implmenting /mnt/9/clone

[Russ Cox]

ls -l /mnt/acme/new on Plan 9 does the same thing.
It's not worth worrying about as far as v9fs is concerned.

Russ

Re: [9fans] implmenting /mnt/9/clone

[Ronald G. Minnich]

On Fri, 29 Jul 2005, Russ Cox wrote:

> Cdfs and sshnet are good examples of this on Plan 9.  Look at those.

thanks. sshnet is *exactly* what I need. It's also (yet another) very 
useful learning tool. 

ron