my fedora 10 prophecy: the unsuckiness of liveusb persistence

[Jane Dogalt]

Actually I hope to get this done ASAP for F9-

============
The problem: 
============

LiveUSB persistence as currently implemented suffers from three really nasty
imperfections.  

1) df -h does not really tell you how much free disk space (aka persistent
storage) you have.  To find out how close you are to the edge of IO errors (aka
disk/persistent-storage full), you actually need to pay attention to 3 things. 
The free space on the root filesystem, the free space in the device mapper
snapshot overlay file, and the free space on the filesystem holding that file. 
It is the minimum of those 3 values that is your real constraint.

2) when you delete files that you have created, you do not necessarily free
space.

3) on your LiveUSB, you have this nice 2GB rootfs compressed into a 700MB
squashfs image, but everything you do in persistent/read-write land is done
uncompressed.  Throw the inefficiency of (2) on top of that, with the lack of
user monitorability due to (1), and what you have is a feature that starts out
looking really cool, but rather quickly dies a horrible death.

=============
The Solution:
=============

(1) is the easiest and most straightforward to solve.  Just write a
mechanism/function/script that exposes the real 'free space' number to the
user, as a fraction of the original amount.  Put this in a little meter on the
gnome-panel along with a command line utility, and call it something
appropriately cute, like the 'life bar' or 'live meter' or such...

(2) and (3) however require a rather more clever solution, which just hit me a
couple days ago.  If you stare at my rebootless livecd/usb installer(a) and
have a good understanding of how livecd-creator formats the rootfs into the
form it exists on the LiveUSB, you might see where I'm headed.

peace...

-jdog

(a)
http://filteredperception.org/smiley/projects/viros/viros-0.5/traits/rliv...

[Jane Dogalt]

--- Jane Dogalt <jdogalt(a)yahoo.com&gt; wrote:
 
>  LiveUSB persistence as currently implemented suffers from three
> really nasty
>  imperfections.  
>  
>  1) df -h does not really tell you how much free disk space (aka persistent
>  storage) you have.  To find out how close you are to the edge of IO errors
>  (aka
>  disk/persistent-storage full), you actually need to pay attention to 3
>  things. 
>  The free space on the root filesystem, the free space in the device mapper
>  snapshot overlay file, and the free space on the filesystem holding that
>  file. 
>  It is the minimum of those 3 values that is your real constraint. 
 
minor clarification- the 3rd constraint only matters if the overlay file is a
sparse file, which, for the current typical use case on a vfat filesystem, is
not the case.

OTOH, since it is possible to (manually at the moment) increase the size of
that file while running, the free space on the filesystem that holds it is a
constraint, but just in a bit more complex way than the min(a,b,c) way I described.