A fuse based initfs

[Jon Nettleton]

On 8/22/07, Douglas McClendon <dmc.fedora at filteredperception.org> wrote:
> Jon Nettleton wrote:
> > This all started with a some what simple task.  I wanted to start rhgb/gdm
> > as early in the boot process as possible.  Basically kernel->disk->gui.  How
> > hard could it be?  Well not fun really.  My finally solution, which is
> > unacceptable for fedora right now is patching the kernel with unionfs and
> > using that as an overlay for /var and /tmp.  That gave me the transparent
> > filesystem overlay I needed to be able to start up a nice gui and allow
> > things like fsck to happen underneath without disturbing things.  Even with
> > this solution I still don't have init restarting gdm if it dies.
> >
> > So I thought, and discarded and thought some more.  Now I want anyone
> > willing to comment on my thoughts.
>
>
> Using unionfs for your rootfs sounds like a currently bad, but
> ultimately very desirable feature.  I would love to have my rootfs have
> a dozen different layers, some of them coming from peer2peer distributed
> filesystems.
>
> But at the moment, using the current unionfs and/or fuse for the rootfs
> seems like a bad idea.  Admittedly, all I can do is wave my hands and
> point to vague memories of lots of issues, but I suspect the issues are
> real.

I really don't need unionfs for the entire root filesystem, but during
the boot process
why not?  Files are really only written to the /var and /tmp
directories.  Everything else
is pretty much all read only.  Plus this is a proof of concept idea at
this point.  I wouldn't
think of unleashing this to the public without a lot more testing.

>
> In general, it sounds like you are outlining several different
> problem/solutions, but I don't think they all need to be as tightly
> integrated as you suggest.
>
> For instance, the gdm in initramfs (or very very early).  Why do you
> need this copy-on-write rootfs stuff?  Why not just have a tmpfs, and a
> gdm configuration that looks there.  Likewise for the early logging
> stuff.  Later during boot, the early-boot logfiles in tmpfs can be
> copied to /var/log.  This isn't as nice as the magic
> unionfs/dm-snapshot-merge automagic merging.  But I don't think that is
> necessary and worth the steps you are taking to get it.

The problem is that all the X gdm talk is through fifo sockets.  This
busies the filesystems
and makes it impossible to just copy things around.  If we want the
boot process to be
smooth and seamless we are going to need some sort of ability to write
to a "read only" filesystem in place.

>
> On the issue of not starting services that might not need to be
> (bluetooth, networking, smartcards, ...), I think in various fedora
> wikis there is talk of DBus as a solution to that problem.
>

I have read this and played around with it a bit.  I have no problems
with it, but there are a lot of services this won't work for.  I am
aiming at a solution that will work with any existing service, no work
needed.

> I think there are some flaws with your strategy (specifically wrt
> unionfs).  I.e. in (4) you mention flushing the fs down to lower layers
> and disappearing.  Can you actually make the unionfs disappear?  Aren't
> there some obscure limitations of unionfs (even when only containing a
> single layer) that will make it unpalatable for the general case?  (I
> have vague memories of something called sendfile and apache, and some
> types of symlinks).

I am working on all of this, and it is one of the reasons I posted my
ideas.  If people have already beat their head against a wall working
on these issues, I am all ears.

>
> Of course if you are talking about devicemapper snapshot merging ala
> markmc's patchset, then I am all for it (just because I have other plans
> for that functionality).  But then I am also confused about using both
> that and unionfs and what exactly you are using for what.

I tried this.  Let me tell you it was a chunk of work to get his
patches working on an existing kernel.  Unfortunately working on a
snapshot and then merging the changes back has the same problem I
experienced with a ramfs, the open filehandles busied the file-system.

>
> But I definitely get the feeling that you are moving in the right
> general direction towards things that I agree should be improved.
>

Thanks for the encouragement.  With all this preliminary work I am
starting to get a much clearer vision on a much easier way to bridge
the gap between our distributions traditional unix background and what
most people expect in a flexible modern desktop.  I am going to keep
hacking on my little project and when I have a working proof of
concept will release it.

I will keep you updated.

Jon


*snip*