[Top][All Lists]

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

Re: ShadowFS (status)

From: Moritz Schulte
Subject: Re: ShadowFS (status)
Date: 02 Aug 2001 18:52:52 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Marcus Brinkmann <> 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. 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.

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

> > 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.

> 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.

> From a quick glance it appears that you create a hierarchy of
> netnodes to represent something like the shadowed filesystem
> hierarchy.


> However, the directory hierarchy is transient, as you noticed.  So
> the path names you store in the netnode may become invalid or
> change.

Only the corresponding path component is stored in the
nodes. Currently 'dead' nodes are not freed - they are simply not

> 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.

> 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?

Thanks for the feedback,

Moritz Schulte <>
Debian/GNU supporter -
GPG fingerprint = 3A14 3923 15BE FD57 FC06  B501 0841 2D7B 6F98 4199

reply via email to

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