help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ShadowFS (status)


From: Marcus Brinkmann
Subject: Re: ShadowFS (status)
Date: Fri, 3 Aug 2001 14:16:38 +0200
User-agent: Mutt/1.3.18i

On Fri, Aug 03, 2001 at 10:36:22AM +0200, Niels Möller wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> 
> > 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.
> 
> An interesting questions is how to handle translators.

They are always the interesting exception ;)

> Should they be
> handled as files (i.e. shadowfs returns the real port of a single real
> file) or directories (shadowfs constructs a node representing the
> union of one or more real directories and returns a port of its own)?
> As far as I understand, there is no sharp distinction between files
> and directories.

Yes, and this can be a plague ;)

> Perhaps the shadowfs should get out of the game and return a real port
> as soon as there is a single matching directory?

A nice idea.  Note that there are two cases, the lookup on the directory and
the lookup below the directory.  In the first case, you return a port to the
directory, in the second you provide a retry port to glibc.
If you decide to do either, you are cutting off the possibility that tan
application becomes aware of files created in other shadowed filesystems
afterwards.  If this is a problem depends on the policies you want to
define.  Should

dport = file_name_lookup ("dir", ...);
fport = file_name_lookup_under (dport, "file", ...);

give the same result as

fport = file_name_lookup ("dir/file", ...);

(Imagine that in the first case, a second dir and dir/file is created that
shades the one in the dport to the real fs returned by shadowfs).
Maybe make this a command line option.  What should be the default?

I think that shadowfs should by default handle directories itself. It needs to
do so anyway for most, and not doing it always is the more complex, and
probably more confusing.  But how directories are treated should be highly
configurable (shadow directories, return directory ports if they are single
anyway).  If someone doesn't expect that the shadowed trees change a lot, he
can make use of this.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]