bug-hurd
[Top][All Lists]
Advanced

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

Re: Unionmount. Basic details


From: Sergiu Ivanov
Subject: Re: Unionmount. Basic details
Date: Tue, 28 Apr 2009 21:47:58 +0300

Hello,

<olafBuddenhagen@gmx.net> writes:
> 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 see... Although I'm familiar with your position as to the power of the
user over his software, I cannot really understand what ``enough rope''
philosophy means... I've googled, but it gave me a TV show only... Could
you please explain? :-)

>> >> 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 see... I was trying to tell exactly this in the above paragraphs, but
forgot about directory nodes... :-(

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

Completely agreed. This is what I was *trying* to stress in the
description of the advantages of the library approach.

Regards,
scolobb




reply via email to

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