[Fedora-livecd-list] Persistance Overlay
Douglas McClendon
dmc.fedora at filteredperception.org
Thu Jun 5 06:03:39 UTC 2008
Jeremy Katz wrote:
> On Wed, 2008-06-04 at 19:12 +0100, Pedro Silva wrote:
>> So, how does the persistance work:
>>
>> - Persistance is created with livecd-iso-to-disk, if I run it again
>> without the overlay flag, previous persistance overlay is deleted?
>
> Yes. Also, the overlay is specific to the *exact* filesystem image that
> it is created for.
>
> ... and for the gory details. The way that persistence is implemented
> is that the persistence file is used as the backing store for the device
> mapper snapshot that we build on top of the "base" filesystem image.
> This means that it contains just changed blocks from the base image and
> that changes continue to build up over time, never reusing blocks from
> the snapshot.
>
> So, not ideal for more long-term cases as if you're updating with yum,
> then you'll run out of space on your snapshot before you'd expect as we
> overwrite things multiple times[1].
>
> Which brings me to what I've been working on this week -- persistence
> purely for /home[2]. So rather than using the persistence file for the
> snapshot backing store, we instead mount it as /home[3]. At this point,
> it's almost to where I'm happy enough with it to push, so stay tuned for
> more details :-)
>
> Jeremy
>
> [1] Plus, your kernel will never get updated
> [2] Actually, implemented such that you can have persistent changes for
> the "OS" as well as a persistent /home. Then your /home sticks around
> when you update the USB stick but any "OS" change disappear as with the
> present bits
> [3] Including support for encryption
Sounds good Jeremy, you know I've always supported this idea because it
helps so many use cases.
FYI- the fixes to the current persistance implementation that I alluded
to before are basically this-
Have a defragmentation process which can merge the snapshot overlay
back. Even if it takes awhile for MarkMC's live kernel snapshot merging
patches to go upstream (which wouldn't help for the squashfs case),
there is actually a fairly straightforward alternative.
You can either have a simple boot choice to run a
'defragmentation/merge' pass while/before booting, or a more complex
version that does it to a running system (using the rootfs swap trick my
rebootless installer uses).
I.e. during the defrag/merge process, you just look at the combined
device (that is in a readonly/unchanging state) and then run mksquashfs
on it to build a new merged version. You'd have to have free space on
the liveusb or disk or ram to handle the transition time where you need
2 copies, but that's not so bad.
-dmc
More information about the Fedora-livecd-list
mailing list