[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Persistant Cows



On 4/6/07, Juergen Fiedler <juergen@fiedlerfamily.net> wrote:
>
> On Fri, Apr 06, 2007 at 01:16:23AM +0200, Marco Amadori wrote:
> > > > Use casper-sn, so a snapshot, it will write only once per session,
> at
> > > > reboot, resyncing the whole /cow onto it.
> > >
> > > Doesn't that one work by copying the files from the snapshot to /cow?
> > > I'm working with some systems that aren't too generously equipped with
> > > RAM, so I don't want to put more stuff on the ramdisk than necessary.
> >
> > Mmmm, time for another type of snapshots?
> >
> > Would you like a add on unionfs on boot (r-o) , then resync from cow at
> > shutdown?
>
> I ended up doing something like that - just without the synching at
> shutdown. I put all the configuration files & such that I wanted to
> keep in an ext2 filesystem in a file and copied that to
> /live_media/casper. That way, it automatically gets inserted into the
> root union, and I can always mount it and ad more stuff if I feel the
> need. I found that that whole autosynching didn't work so well for me
> because it also preserved things that I didn't want to preserve, like
> information about my network setup - which made it somewhat hard to
> move the boot media between different computers.


Does casper-snapshot -e <the stuff you don't want to persist> can help?

To make a long story short: I think modules in /casper are the right
> solution for me right now; it would be cool if anyone came up with a
> good approach for syncing the files in those modules conveniently


I wonder what could be a good approach - IMHO there are pros and cons in
each approach...
Currently on shutdown, you create a "module" in casper that represents the
changes from the latest seesion.
Each session that involves changes will result in another file and branch in
the unionfs. The problem with this approach is the storage redundancy and
the overhead on the unionfs because you have a branch per session.

Another approach is to manage only one changes module. On boot this module
is extracted to /cow (RAM), so following writes are made to /cow. On
shutdown, this /cow is compressed again and saved on casper directory.
In this approach cons are RAM consumption and slow shutdowns because of the
big compressions.
OTOH, the disk consumption is lower and the overhead caused by unionfs is
almost zero (only two branches).

When there are massive updates, the first approach might be better.
Otherwise I would go with the second, and manage only one changes file. If I
missed something please add :)

Regards,
Hadar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/debian-live-devel/attachments/20070411/2f89aa2e/attachment.htm

Reply to: