Re: ShadowFS (status)

[Marcus Brinkmann]

Hi,

sorry, I was a bit slow today.  There are some issues I was not completely
clear on (well, there still are, but some less).

On Thu, Aug 02, 2001 at 06:52:52PM +0200, Moritz Schulte wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > On Thu, Aug 02, 2001 at 03:15:38PM +0200, Moritz Schulte wrote:
> > > It's netfs_attempt_lookup() job to find out, which file (in string
> > > form) the user wants and which file (port) the user gets. This port
> > > has to be stored somewhere, assigned to that access - but where?
> > 
> > What is wrong with storing it in the struct netnode?
> 
> A node doesn't always point to the same underlying file. When user A
> opens the file /shadowfs/foo he should get a port to the underlying
> file.

Yes, this is important.  The user will get the port from the other
filesystem, and not a port from shadowfs.  In this sense, shadowfs is an
aggregation of cross-filesystem hard links in a new directory tree (which is
the union of the other directory trees).

> Now, when user B opens the same file and the state of the
> underlying filesystems has changed in that /shadowfs/foo points to a
> different file, user A shouldn't notice it. Once you've opened a file
> from shadowfs you should have a port always pointing to the same file.

No.  Each open() results into a new lookup and a new port.  There is a port
for each opened file, not for each file.   Also, these ports are not ports
to shadowfs, but to the translator providing the real file.

> This is why nodes in shadowfs can't simply be connected with
> underlying files (or ports), but _accesses_ have to be. That's my
> thought.

I think you are trying to slice it at the wrong place.  I/O and file operations
on files should not be routed through shadowfs at all.  They go directly to the
real filesystem providing the file (the hard link idea).  Just like the fwd
translator, IIRC.
 
> > > Since a 'struct iouser *' is passed to all the netfs callbacks, i
> > > though about storing this port to the backend file in the 'hook' of
> > > 'struct iouser'. But, this seems ugly to me.
> > 
> > A struct iouser identifies a user, not an opened file.
> 
> I thought such a iouser is also created for each open.

The iouser is duplicated for each open, but it is not what defines the
iouser.
 
> > struct peropen is what is created for each opened file, and this in
> > libnetfs points to a struct node and this in turn to a struct
> > netnode.
> 
> Yes, exactly. But, how can i use that peropen? libnetfs doesn't pass
> it to the callbacks.

You can not use it directly (in libtrivfs you get a hook).  Anyway, I was
wrong in the first place, as shadowfs should not provide file ports at all.
 
> > I have not pondered shadowfs details at all, so I might be wrong,
> > but it seems to me that you want to create netnodes and nodes only
> > for opened files,
> 
> I thought, one of the reasons for saving all accesses nodes is to
> guarantee unique filenos.

The inode number issue was what brought my thoughts back in place:  The
filesin the shadowfs should have the *same* fsid and fileno as the original
files.  This should not be done by shadowfs (although it could be done). 
shadowfs just provides another way to access ports from other filesystems.
 
> > and not store the filename in a netnode, but a port to the real
> > file.
> 
> Hmmm. How can I then handle the case that the underlying filesystems
> change while the user is using nodes?

As the user has a port to the real file, all changes to the real file are
handled by the real fs providing the node.  shadowfs is out of the game as
soon as the lookup is over.

shadowfs just needs to provide ports for directories, and implement the
operations on those directories.  If a user lookups a file, shadowfs just
does a lookup on the relevant other filesystem and returns THAT port to the
user.

like, if /tmp/a/a1 is a file with fsid/fileno  1/1, and /tmp/a/a2 is 1/2
and /tmp/b/b1 is 2/1.  And then you shaodw those on /tmp/c, which has fsid
3.  The ls /tmp/c would return a listing a1, a2, b1, but any lookup on those
files will be identical to lookups in the corresponding real filesystems.
A stat on /tmp/c/a1 would be identical to a stat on /tmp/a/a1.

Mmmh.  This has certainly some issues.  The cross-filesystem hard links are
not like real hard links, as the link count will not include them.  They are
a new type of files, which is outside of POSIX.  I don't think this will
cause any real problems.  However, you might watch out for such things.

It is possible to create real nodes in shadowfs, and forqward all rpcs on
suchports to the corresponding real port.  However, this is considerably
more work for little gain (you would not have the strange cross-fs hard
link), AFAIKS.

What you indeed need to take care of are directories in shadowfs, and ports
to those directories.  Each time someone opens a directory, he will get a
new port to shadowfs describing the directory (via struct netnode/node)
and the user/access rights.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de