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

[Jeremy Katz]

On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote:
> 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

Weird.  In any case, I'm also now an admin for the list, and like I
said, I've _hopefully_ adjusted things so they should work anyway.
We'll see I guess.  And review coming up from looking at the patch
next...

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

It's been quite a while since I looked at unionfs, but I vaguely
remember that it was more subtree overlays.  I guess you could perhaps
do a subtree of /.  But even so, I don't know that supporting multiple
ways of achieving the same goal is really where we want to go.  But it's
somewhat academic at the moment, so probably not much discussion needed.

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

I say let's just pull it.  If it doesn't work right now, we might as
well save the effort of testing it and/or someone trying it, finding it
doesn't work, and filing a bug.  Plus, it then makes the changes clearer
for looking at.

Jeremy