On 4/6/07, Juergen Fiedler <[EMAIL PROTECTED]> 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
_______________________________________________ Debian-live-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
