[Top][All Lists]

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

Re: Unionmount. Basic details

From: Carl Fredrik Hammar
Subject: Re: Unionmount. Basic details
Date: Fri, 17 Apr 2009 18:01:20 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Mon, Apr 13, 2009 at 12:41:07AM +0300, Sergiu Ivanov wrote:
> [snip]
> >> 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?

That depends.  You'd need to proxy the control port, and any port from
which you can get the control port.  I was assuming that it's only possible
to get it from its mount point or perhaps its root.  But if its possible
to get it from any file node you'd need to proxy them all.  And the existence
of the file_getcontrol RPC seem to imply the latter.  :-(

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

Any node involved in getting the control port.

> >> 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 :-)

It is possible to handle them as long as there is a unionmount process.
This really has nothing to do with forking versus not, it was only a
problem when considering pushing the implementation to system servers
so that no extra unionmount process was needed.

> [snip]
> > 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 :-)

Well it all comes down to whether you are comfortable with doing it
or not.  We can always return to the idea later.  I would take it up,
but it will have to wait until I've done my thesis on libmob.


reply via email to

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