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

Splitted live-snapshot patches + some comments on snapshot internals



Marco Amadori <marco.amadori at gmail.com> writes:

> And now, for something completely RELATED:
>
> If I'll can I'll try to add a cpio.lzo target before the freeze; it is really 
> useful for slow systems since lzo is a very fast compression library, although 
> it is not a good candidate for replacing the default "cpio.gz" since the 
> latter is supported by busybox and klibc without external dependencies.
>
> The squashfs target is meant to be built in order to put it side the main 
> filesystem.squashfs on CDRW multisession open media, here an helper to reburn 
> just this snapshot would be great.
>
> The latter ext2 is meant to ease the creation of the "Cow" persistent media 
> instead of using tmpfs which is the original casper solution for persistence 
> from ubuntu. But this way has proven to be slow in practice, although is the 
> most "unplug power cord" friendly one.

Could you give a better explanation how this tmpfs solution used to
work? I didn't see it and would be interesting for a whole situation
understanding.


> Both squashfs and ext2/3 target was only tested by me 2 years ago and worked 
> boot-wise. 
>
> BEWARE:
>
> Now cpio.gz is the only guaranteed target (fully tested by me on iso media  
> with the /etc/live-snapshot.list option).
>
> All other targets will fail until "/live/cow" will became visible again (this 
> bug is related with busybox/klibc recent mount changing, should be like the --
> move support btw).
>
> Squashfs support at boot was also added to support modules and hence the 
> concept in live-package (at that time) to build differents squashfs 
> incrementally, designed like it shoulded mounting at build time (now by live-
> helper) the chroot from the previous squashfs sets and a writable dir as the 
> cow, source of the new squashfs module block.
>
> But this could be a nice thing to have in lenny+1 since I just wrote a concept 
> for a old build system.
>
> A little brainstorming could help here to provide the most useful and flexible 
> "writeable" on a read-only media option to our users. There are many bugs and 
> missing features now, like deleting files (which needs .wh. whiteouts 
> internals of aufs/unionfs, or implementing custom mass delete at boot) or 
> copying only file which are really changed to save spaces.
>
> Any wishlist or ideas on snapshot/persistent topic here?

I've been using ext3 since ext2 corrupt too easily.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio at debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."



Reply to: