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

[unlimitedscolobb]

Hello,

On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafBuddenhagen@gmx.net wrote:
> 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:
>
> > > 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 ;-)

Well, I didn't expect the previous version to be final :-) But that's
not a problem :-) I wonder, whether this version is final, though?..
 
> > > "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?
[...]
> > 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?
[...]
> Exactly.

OK.  I've changed the comment accordingly.  Namely, the sentence now
looks like this: ``This node is based on the netnode of the root node
(it is essentially a clone of the root node), because in this way
unionfs appears as the underlying translator to the mountee.''

> 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 :-)

I think we should adopt some conventions in order to remove the
ambiguity of the word ``underlying''.  I'd suggest using ``underlying
translator'' to specify the order of translators in a stack,
``underlying filesystem'' for the real underlying filesystem, and
``unioned directory'' for one of the components of the union managed
by unionfs.

I'm strongly inclined to consider the term ``underlying filesystem''
used for a unioned directory to be unwieldy chosen: firstly, unionfs
is not operating on filesystems, and secondly, the directories it
operates on are not underlying to it.
 
> > 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...

Yeah, that's my opinion, too.
 
> 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...

Yes, this is what I considered doing, but haven't yet found the time.

Regards,
scolobb