Hello, <olafbuddenha...@gmx.net> writes: > On Thu, Apr 09, 2009 at 10:03:27PM +0300, Sergiu Ivanov wrote: >> <olafbuddenha...@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
