The real need is a compressed file system because allow a lot of data inside a little space. I think btrfs is not support compress. This is SquashFS job. The LZMA is a compress algorithm to allow more data in SquashFS. AuFS is the glue between the other components and persistence. Finally the result filessystem (eg.: live/filesystem.squashfs) is beautiful. If was used btrfs is a lot of directory with habitual strange names (eg.: boot/, opt/).
2010/11/12 Philippe Lelédy <[email protected]> > As CD-ROM are becoming legacy and USB ubiquitous, it is possible to think > about live systems without the focus on there beeing Read-0nly OSs. > > For my use case, live system is mainly a system where most configuration > are post-poned from install time to boot time, with four main benefits: > > 1) Portability: the same OS is used on many different locations, different > hardware > 2) Clonability: making a new USB live out of an existing one is mainly a > matter on unattended copy > 3) Ability to reverse to a known working state > 4) Compression. > > I start thinking that btrfs can be used to offer these features with > increased flexibility over our usual tools. > > More generally, I observe that more and more live features are going to > mainstream OS: I mean there is a strong trend for post-poning configuration > from install time to boot time for ordinary OS. Some examples: - DHCP, -NTP > , mount -L <LABEL> , X which doesn't need anymore an xorg.conf file. Some > of the hard work done but live-CD pionners is no more useful. The feature 1) > Portability and 2) Clonability will become the general rule, not the live > systems niche. > > So I feel that now btrfs is giving us all the features that we previously > had to build upon various tools. > > Why could btrfs replace squashfs, lzma, aufs ?: because btrfs is based on > COW. > > How ?: > > a) Install the chroot created by lb buid on a btrfs partition on a USB key > with compress option ( feature 4). > a') Do once for all most of the stuff done by live-config > b) Take a snapshot (feature 3) > c) In live-boot offer the user to use any snapshot, so the persistent > feature and incremental updates are implemented in a very powerful way. > > Btrfs snapshots are very close to using an overlay FS like > aufs:cow=rw,rofs=rr. It uses very little space and time to take a snapshot. > For instance taking a snapshot every day is realist, because btrfs always > use cow, so, taking a snaphot only means that all space used by data that > has been obsoleted is not freed, and that an anchor is saved to allow access > at the data as it was at the time the snapshot was taken. No data is > duplicated until some update occurs. Using a snapshot is as simple as a > mount and they are writable. One feature is perhaps missing, using memory > (tmpfs) for files updated, but perhaps some mount options should give about > the same effect. > > Now the main concern for me starting using this scheme is the effect of a > journaling FS on the lifetime on a cheap USB flash disk, and of course the > fact that btrfs is still experimental and lacks some vital features like > deleting snapshots. > > Ph. Lelédy > > > > > > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: http://lists.debian.org/[email protected] > > -- Marcos Henrique Esteves Barbosa [email protected]
