Re: Is not btrfs about to replace our main live tools like squashfs, lzma, aufs, ... ?
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 <firstname.lastname@example.org>
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
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.
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.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Archive: [🔎] 4CDDA8B6.email@example.com" target="_blank">http://lists.debian.org/[🔎] 4CDDA8B6.firstname.lastname@example.org
Marcos Henrique Esteves Barbosa