Re: Unionmount. Basic details

[olafBuddenhagen]

Hi,

On Thu, Apr 09, 2009 at 10:03:27PM +0300, Sergiu Ivanov wrote:
> <olafBuddenhagen@gmx.net> writes:
> > On Mon, Apr 06, 2009 at 04:26:25PM +0300, Sergiu Ivanov wrote:

> >> This approach will require adding some user-modifiable flag to the
> >> corresponding translator library that will allow to switch on and
> >> off this functionality, because not all translators would be happy
> >> running in unionmount mode.
> >
> > It should be the user's decision whether to try union-mounting or
> > not.
> 
> I was trying to think of a specific translator which would publish
> such a specific file system that it will not make sense to union-mount
> it. However, I couldn't think of something real (even /proc may be
> union-mounted for some purpose), so I agree that it should be the
> user's decision whether to use union-mounting or not.

Even if you had found examples of translators that really don't seem to
make any sense being union-mounted (which seems quite probable
actually), I still think it should not be up to the translators to
decide this. If the user thinks it is a good idea, let him try it. You
know, "enough rope" philosophy of UNIX...

> >> I am aware of the performance issue about extra context switches,
> >> but if the unionmount translator will not give off ports to its own
> >> nodes, but ports to *external* nodes (underlying filesystem nodes
> >> or those published by the Translator), it will not take part in the
> >> frequent (and most time-critical) I/O operations and act as an
> >> initial source of ports only. I think it is reasonable for
> >> unionmount not to create proxy nodes (in nsmux terminology),
> >> because I cannot presently invent a use case where it will need
> >> control over the ports it gave off to the client.
> >
> > Well, the situation is exactly the same as for ordinary unionfs (and
> > nsmux): It should be fine in normal use cases -- although it might
> > be possible to construct scenarious where it would break...
> >
> > Also note that this problem would only be half solved by the library
> > approach: while the nodes provided by the target translator would
> > not need context switches (as the merging happens in the same
> > process), the nodes of the underlying file system require the same
> > kind of proxying as with an external unionmount translator (or
> > unionfs).
> 
> I'm not sure I can understand correctly what you mean. Why should the
> underlying nodes of the filesystem require proxying? Why couldn't we
> just give off ports to real nodes instead of creating proxies?..

Again, the situation is *exactly* the same as with unionfs: We need to
proxy directory nodes, so we keep control over further lookups; while
for file nodes, we are probably fine giving out the real unproxied
ports.

I think there is some context lost here: this discussion was started by
the suggestion that implementing the unioning functionality in a library
would save context switches. For directory nodes, this is partially
true, as they need to be proxied (see above); and if the actual unioning
happens in a library as part of the mountee, the proxying would not need
a context switch, for all nodes served by the mountee. The directory
nodes served by the underlying filesystem would still need context
switches though, as the unioning inside the mountee would have to
forward the requests to the underlying filesystem.

-antrik-