Hi! On Tue, Apr 07, 2009 at 12:20:40AM +0300, Sergiu Ivanov wrote: > > Then it might be possible to implement the shadow node in unionmount > > and pass it to unionfs. Just wrap a file descriptor around the port > > and let unionfs inherit it, to make unionfs use it pass `/dev/fd/$FD' > > as an argument. > > > > If you're uncomfortable keeping around a process just to implement > > a shadow node, consider implementing a dedicated shadow node server. > > That just sitts on e.g. `/server/shadow' and passes out shadow nodes in > > responce to RPCs of a new kind. > > > > I think such a server might be a good idea in any case. Shadow nodes are > > already needed by nsmux (right?) and seem generally useful for creating > > ``anonymous'' file systems. The only real question is wheather they > > are independant enough to be put in their own server. > > Yep, I'm really uncomfortable about keeping around processes, but in > this case I'm inclined to think that spawning an extra process would be > an overkill. I'm more inclined to the simpler variant of borrowing the > code from unionfs, stripping off the unnecessary features and modifying > the startup sequence to get a new translator.
Well it isn't simpler in the sense that we'd need to maintain two very similar yet different code bases. Improvements to one would likely get ported to the other. > This would yield faster code (no extra context switch, the shadow > node is within the main translator) and more control over the merging > functionality. Isn't the shadow node used mostly by the mountee? If so it will be used through RPCs in any case. I don't think there would be any extra context switches, they would just be divided between different processes. An extra process per mount is no big deal IMHO. > You see, I suppose that some time later we will be adding some specific > merging rules, which would be very difficult (if not impossible) > with the approach you are suggesting (about reusing unionfs as a whole). OK, here we have a more concrete reason to fork unionfs's code. However, I can't think of any rules that wouldn't also be useful in unionfs. Have you got anything in particular in mind? I'm guessing that it's easier to turn a unionmount that uses unionfs to one that uses code from unionfs, then the other way around. I wouldn't start by forking the code-base unless I *knew* that I would do it eventually. > I like the idea of a shadow-node server :-) However, I would rather keep > shadow-nodes inside processes, because they are cheap as compared to > RPCs and you have full control over them. Moreover, some translators > (like unionfs and hence unionmount) would like to keep a list of nodes > they own and drop nodes when they don't need them. This policy would > require more effort if a shadow-node server is involved. Does unionmount (or nsmux) need to do anything except keep them around and destroy them when not needed anymore? It seems easy enough to destroy a node through RPCs, just unlink it or something. If not it should be easy enough to create a shadow_node_destroy RPC. Also unionfs itself should only be interested in the mountee and the underlying filesystem, not the shadow nodes (AFAICT). Thinking about it, clean-up presents some problems with ditching a unionmount process. The mountee becomes effectively orphaned when unionfs dies. With no way to reach it from the file system, the user would have look up its PID to kill it. To handle fsys_goaway requires that there be a proxy for the ports that receives it and forwards it to the mountee and, if that doesn't fail, forwards it to unionfs. You probably know, but I'm hoping there's only one such port. In a pinch, this could also be implemented by a server shared by all unionmounts. Now the question is what to do if unionfs crashes or is killed. If there where a unionmount process it could detect it and ask the mountee to go away. Doing without is harder. The only solution I can come up with is letting unionfs inherit a port to a server that kills the mountee when there are no send rights to the port. But that seems like a really weird hack. Of course, implementing such servers would be a long term goal. This is just to convince you that it's possible to reuse unionfs without an additional process per unionmount. Admittedly, these solutions are aren't very pretty, but then again I don't think an extra process per unionmount is a problem at all. ;-) Regards, Fredrik
