devicemapper and stateless? (was Re: who needs unionfs!, was Re: [Fedora-livecd-list] experimental unionfs and initramfs code)

[Jane Dogalt]

--- Bill Nottingham <notting at redhat.com> wrote:

> Bill Nottingham (notting at redhat.com) said: 
> > > I just saw this go by on planet.fedoraproject.org::
> > > http://blogs.gnome.org/view/markmc/2006/04/25/0
> > > 
> > > notting or jeremy: Is markmc working on something like this as part of
> > > stateless or is the devicemapper work he's doing totally unrelated?
> > 
> > It's related, but it's not part of the readonly-root support. Using
> > something like device-mapper for that means you'd have to use a block
> > device.
> > 
> > What LFS appears to be doing is creating a sparse loop device on tmpfs,
> > and using that as the block layer. It's a interesting idea, and bears
> > investigation.
> 
> However, one of the downsides of this approach is it (essentially) makes
> the whole root filesystem read-write, which loses some of the benefits
> of readonly-root (and makes it a whole lot easier to DoS yourself.)

This is basically just an alternate implementation of unionfs.  I asked a while
back what the RH kernel developers thought as far as that, and apparently dm is
the implementation they consider worthwhile.

I'm currently trying to ping Jeremy Huntwork regarding whats going on with the
LFS livecd init code.  I.e. why the move away from squashfs to ext2.  Is that a
limitation of the dm union/overlay/snapshot implementation, or was there
another reason.

Does anyone here know off the top of their heads if enough of the dm kernel
stuff is already in place in fc5 to do this already?

I know that complexity can be a bad thing, but I'd like to see livecd
generating tools give as much flexibility as can be reasonably modularized by
the generator.  I.e. I think a good generator, given the read-only-root infra
provided by stateless, should give both that as an option, and a union
implementation (or two) as options.

Since you can set maxsize on tmpfs, using a writable root overlay IMO is a very
beneficial feature (at least as an option).  Clearly by the large number of
livecd implementations that already do this with unionfs+squashfs, I don't
think the risks involved with it outweigh the benefits.

And in general, having the overlay/union infrastructure opens up a plethora of
funtionality options.  I.e. slices of the union coming from disk, flash,
network...

-jdog



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com