[Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only

[Jeremy Katz]

On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote:
> (I'm getting a sense of deja vu, that I'm learning the same lesson
> someone else recently learned here.  Lets see if the 3rd time is the
> charm...)

It looks like you're getting hit by what Colin was where the list is
eating some attachments :-/   FWIW, the "best" way of sending patches
directly from git is git-format-patch followed by git-send-email; I need
to sit down and write up some simple docs for using git + livecd-creator
and best practices.  Where's that 36 hour day? ;-) 

I'll try to get access to the list admin page later and try to tweak
stuff to avoid the problem later as I suspect it's that one of the
default mailman settings blocks attachments that look like mail to avoid
some of the WINMAIL.DAT crap.

> Attached is a revision to the persistence implementation that I posted a
> couple weeks ago.  This is mainly for Jeremy, Tim, and anyone else who
> is interested in working on this, or something similar.  I.e. at the
> very least, it is worth a read to look at the issues I've dealt with,
> and the several that are in comments as TODO.

Since the patch isn't attached, I'll guess.  This is still doing a file
which is loopback mounted and then added to the dm device?

> It may well be that a simpler persistence implementation that involves
> just extracting tarballs from usbsticks into the normal ram overlay, may
> be useful instead of (or even in addition to) this kind of
> implementation.  (or perhaps some implementation of unionfs will make it
> into fedora eventually?)

There's work on doing unionfs via fuse which could be interesting for
that in the medium term.  But I'm not sure how useful tarballs/unionfs
are when we think about the user experience.  If it's going to persist,
we want changes to "persist" as soon as they're done, not after some set
of stuff is done to apply them.

> The main points of note, since the first post are-
> - all sorts of bugs fixed
> 
> - I moved the overlay storage filesystem to be visible as /mnt/overlayfs
> always.  This solves some aspects of the current problem of not easily
> being able to see how much writable space you really have available on
> the rootfs.  (the real answer is a combination of the device mapper
> overlay file AND the filesystem it resides on).

This sounds good.

> - I've included modified /etc/rc.d/init.d/halt and functions, to handle
> getting things cleanly shutdown (which is VERY important)

And can see about getting these integrated with the initscripts bits.
Shouldn't be too bad to do

> - ntfs is somewhat present, but not really working.  I have tested with
> vfat and ext3.  Note that ext3 is a PITA when not cleanly unmounted- see
> TODOs.

Let's make things simpler for the moment and just ignore ntfs.  If we
get things happy with ext3 and vfat, then we can start to think about
ntfs.

> - rudimentary testing of the choice selection when multiple possible
> overlay images are detected suggests it works.

Cool.

Jeremy