Re: Unionmount. Basic details

[Sergiu Ivanov]

Hello,

Carl Fredrik Hammar <hammy.lite@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