[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 <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. 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
thought.
> > 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.
Right.
> 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
used.
> 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
--
Moritz Schulte <moritz@chaosdorf.de> http://www.chaosdorf.de/moritz/
Debian/GNU supporter - http://www.debian.org/ http://www.gnu.org/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
- ShadowFS (status), Moritz Schulte, 2001/08/02
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/02
- Re: ShadowFS (status),
Moritz Schulte <=
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/02
- Re: ShadowFS (status), Moritz Schulte, 2001/08/02
- Re: ShadowFS (status), Niels Möller, 2001/08/03
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/03
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/03
- Re: ShadowFS (status), Niels Möller, 2001/08/03
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/03
- Re: ShadowFS (status), Moritz Schulte, 2001/08/03
- Re: ShadowFS (status), Moritz Schulte, 2001/08/03
- Re: ShadowFS (status), Marcus Brinkmann, 2001/08/03