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

[Douglas McClendon]

Jeremy Katz wrote:
> 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.

Hmm...  The 3rd time did appear to be the charm for me.  Perhaps your 
email client is eating a broader class of attachments than the list 
itself.  To see the patch, see the archive link of the post you replied to-

https://www.redhat.com/archives/fedora-livecd-list/2007-August/msg00168.html

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

correct.

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

Well, the way ubuntu is trying to do it of course, is with unionfs 
(since of course they use unionfs rather than dm-snapshot to get cow in 
the first place).

And as such, unionfs can provide just as persistful an implementation as 
the direction I've been going.  In both cases you can think of the 
persistence as another embedded layer in the total root filesystem.


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

I was ignoring ntfs, though not enough to remove the stuff that could 
support it.

-dmc

> 
>> - rudimentary testing of the choice selection when multiple possible
>> overlay images are detected suggests it works.
> 
> Cool.
> 
> Jeremy
> 
> --
> Fedora-livecd-list mailing list
> Fedora-livecd-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-livecd-list