Re: [PATCH 2/3] Implement mountee startup.

[olafBuddenhagen]

Hi,

On Wed, Nov 04, 2009 at 10:10:43PM +0200, Sergiu Ivanov wrote:
> On Thu, Oct 29, 2009 at 06:37:54AM +0100, olafBuddenhagen@gmx.net
> wrote:
> > On Mon, Aug 17, 2009 at 07:15:09PM +0300, Sergiu Ivanov wrote:

> > > I won't submit patch with corrections you mention in this E-mail
> > > right away, because the corrections are mainly about changing some
> > > comments or strings and I think it will be harder for you to
> > > review the changes if I post the whole patch again.
> > 
> > Well, I can't really give a final ACK without seeing the whole patch
> > in its final form...
> 
> I'm sending the current version of the patch in this mail.

Actually, it's not useful *this* time, as we are still discussing some
of the comments, and you haven't updated them yet -- so it can't be the
final version anyways :-)

Perhaps you didn't expect the previous version to be final either -- if
this is the case, please pretend I never said anything about this ;-)

> > > Changed to: ``The mountee will be sitting on this node.  This node
> > > is based on the netnode of the root node (it is essentially a
> > > clone of the root node), so most RPCs on this node can be
> > > automatically carried out correctly.  Note the we cannot set the
> > > mountee on the root node directly, because in this case the
> > > mountee's filesystem will obscure the filesystem published by
> > > unionfs.''
> > 
> > "most RPCs ont this node can be automatically carried out correctly"
> > is way too vague... It's not ever clear what "correct" means in
> > here, no what RPCs you mean.
> > 
> > I think you should say that the mountee is set on a (clone of) the
> > unionfs root node, so that unionfs appears as the parent translator
> > of the mountee. AIUI that's the idea behind it, right?
> 
> What exactly do you mean by ``parent translator''?  I must acknowledge
> I haven't heard the term ``parent'' applied to translators (I can
> attribute it to processes only).
> 
> Do you want to say that the goal of setting the mountee on a clone of
> the root node is to make unionfs appear as the underlying translator
> to the mountee?  If so, then yes, the idea behind cloning is really
> this one and I will change the comment accordingly.

Exactly.

I didn't want to use the term "underlying", because in the context of
unionmount, we always used it for the underlying filesystem of the
unionfs node; which, in the non-transparent case, is not the same as the
underlying filesystem of the mountee... But feel free to use this term,
if you think it causes less confusion than introducing completely new
ones :-)

> > > > Why are you passing O_READ, anyways?...
> > > 
> > > The flags which I pass to start_mountee are used in opening the
> > > port to the root node of the mountee.  (I'm sure you've noticed
> > > this; I'm just re-stating it to avoid ambiguities).  Inside
> > > unionfs, this port is used for lookups *only*, so O_READ should be
> > > sufficient for any internal unionfs needs.  Ports to files
> > > themselves are not proxied by unionfs (as the comment reads), so
> > > the flags passed here don't influence that case.
> > 
> > Hm, but wouldn't unionfs still need write permissions to the
> > directories for adding new entries, when not in readonly mode?...
> 
> Well, obviously, O_READ permission on a directory is sufficient to
> create files in it.

Ah, interesting...

> I'm not sure whether this is a feature or a misbehaviour

I don't think it's a bug -- doesn't seem very likely that nobody would
have noticed such a fundamental bug all this time...

But feel free to investigate this further, reading some relevant POSIX
man-pages, and/or the server code implementing file creation. Or perhaps
it would be easiest to try reproducing it with standard POSIX functions,
both on Hurd and on Linux...

-antrik-