Hello, Carl Fredrik Hammar <hammy.l...@gmail.com> writes: > On Fri, Apr 10, 2009 at 08:35:07PM +0300, Sergiu Ivanov wrote: >> Anyway, I'm not sure whether bringing some details in the code in >> unionmount up to date will require ``porting'', since I'm going to touch >> only a very small portion of the code, leaving the bulk of it intact. >> >> Also, I'm not aware of anybody still doing any changes to unionfs :-) > > I don't know the current state of unionfs myself, but I'm assuming it > still has bugs. And I'm not (yet) convinced that any rule you'd add to > unionmount would be not be useful it unionfs or the other way around. If > unionmount uses unionfs it benefits from improvements to it automatically.
I agree with your assumption, however, my personal opinion is that reusing unionfs as a whole in unionmount will not really reveal the bugs, because the use case is a very simple one. > Also, in many ways unionfs seems like an good candidate to make use of > libmob which I'm working on. Making that that change would hopefully > not be too extensive, but it would not be trivial. Hm, interesting, I didn't think of that... Still, sincerely, I'm a bit afraid of the fact that things tend to get more complicated when reusing unionfs as a whole :-) I'd rather ``keep it simple''. Anyways, the final decision is up to antrik. >> This is true that in the greater part of the operation of unionmount >> there will be no difference in speed (the difference will be at startup, >> of course). However, I still don't have sufficiently compelling reasons >> to considering making the startup sequence more sophisticated. > > I don't think the start up sequence will be very complicated: > > 1) open a port to the mountee's root > 2) wrap it in a file descriptor (make sure it will be inherited.) > 4) fork and exec > "settrans $st_args $mount_point \ > /hurd/unionfs $unionfs_args /dev/fd/$fd $mount_point" > 5) close port and file descriptor > 6) stack the go_away interceptor over (the new) $mount_point > > Of course, you'll be the one stuck with handling the details. In the end > it might be a lot more complicated than I think it is. Hm... I'm not sure I can fully assess the complexity of ``go_away interceptor'' (whose structure is a bit obscure to me). Also, I'm afraid that the interceptor might introduce an extra context switch in each RPC, what do you think? >> When unionmount is a fork off unionfs code base, it has *full* control >> over the mountee and can do whatever it wants to it. When unionmount is >> requested to quit, it can gracefully shut down the mountee, thus doing >> all the cleanup required. > > You'd still have to handle fsys_goaway differently than unionfs. The > extra work in reusing unionfs would be to forward all other RPCs to the > node and setting it up. I'm not sure I can understand completely your idea... What node do you refer to? >> Having the mountee killed after unionmount is (forcibly) killed may not >> always be the desired effect, you know. I would rather have unionmount >> die on its own, but this is just an inclination, not a founded >> opinion. Personally, when I kill -9 a program, I am very much prepared >> to go after it and to collect all the garbage. > > Oh I agree. The problem concerned with crashes and non-KILL signals to > unionfs, without a unionmount to clean up. A unionmount process could > trap non-KILL signals and handle them gracefully. Yes; and this is another thing that makes me an adept of the ``fork-the-code-base'' approach :-) >> > 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. ;-) >> >> I see :-) Well, I should say that an additional process per mount is not >> a problem, indeed, but I don't really see so far why we need this extra >> process so much, if can go without it? :-) > > Well I've already mentioned the advantages of reusing unionfs. And I do > think we should reuse it if it doesn't require changes to unionfs itself > that aren't natural extensions of it. > > However, all the ifs and buts are starting to add up. Perhaps it would be > safer to start by forking unionfs, and then rewrite it to reuse unionfs. You know, this probably is the way which will be accepted, although I can't tell for sure. In any case, I understand pretty well the advantages of reusing unionfs as a whole. > There is one more route you may want to consider. As I mentioned in > my replies to antrik, unionmount is basically anonymous file systems + > unionfs. You could write a utility to handle anonymous file systems > instead. Even if it turns out that a specific unionmount with special > rules is needed, we'd still get a very useful utility out of the > process. Yes, this is true. The idea of anonymous filesystems is very interesting; but I must acknowledge that I don't know many of the involved details. I guess there will be a need for a discussion about anonymous filesystems soon :-) Regards, scolobb
