Re: [Fedora-livecd-list] Expanding the overlay size

[James Heather]

I don't have a full answer, but I can tell you why df is being so
carelessly optimistic.

The build process creates an ext4 image of a certain size (defined in
the kickstart file), and then installs the packages into it. This image
gets compressed into a squashfs image.

When the ext4 partition gets mounted, it still has the same size as was
defined in the kickstart. It is mounted read-write because of the
overlay. But what df is seeing is the 'free' space in the ext4 image,
i.e., the difference between the partition size and the installed
contents. It doesn't take the overlay size into account. So if you have
an 8GB partition and install 2GB of stuff to it, df will report 6GB free
regardless of the size of your overlay. You can write to it until either
the partition is full or the overlay is full; if it's the latter, then
it'll suddenly become read-only and your system will almost certainly
crash horribly.

James

On Mon, 2011-10-03 at 17:33 +0100, Phil Meyer wrote:

>  On 10/03/2011 09:59 AM, Phil Meyer wrote:
>  > The livecd images currently appear to have 4GB filesystems, which would
>  > correspond to single layer DVDs. This is ok.
>  >
>  
>  Some follow up thoughts.
>  
>  We have built other platforms using NFS with RHEL6 using the 
>  /etc/sysconfig/readonly-root and /etc/statetab.
>  
>  Understanding that the basis of the livecd overlay is based upon a 
>  RAMDISK, I wonder if the same could be used as a solution for what I 
>  want to do.
>  
>  Here is the goal:
>  
>  Appliance computing, such that a generic livecd image self modifies upon 
>  boot up based upon class and/or system specific specifications.
>  
>  We have completed some rather complex examples and the results are very 
>  desirable.  The only draw back is the inflexibility of the overlay size.
>  
>  Permanent storage is always desirable for data collection, but many 
>  virtual machines and hardware based systems in use today are single 
>  task, and require little or no permanent storage.  We are targeting 
>  these types of servers for our appliance model.
>  
>  Some examples are:
>  
>  Virtual machine servers.
>  Load Balancers.
>  Database compute nodes (external storage, of course)
>  
>  and the list goes on.
>  
>  The benefits are greatly reduced systems administration.
>  
>  My old work system can roll a new version of the generic livecd we are 
>  using in 6.5 minutes, and automatically copy it to the pxe servers 
>  without impacting any production servers.  As new servers come online or 
>  are rebooted, they pick up the new version.
>  
>  For example:
>  
>  We have completed a test of our Virtual hosting platform using a livecd 
>  image for the servers.  To upgrade the OS of the servers the following 
>  procedure is performed:
>  
>  1. Rebuild the livecd image and copy it to the pxe servers (about 8 
>  minutes total).
>  
>  2. Migrate away from host one.
>  
>  3. Reboot host one.
>  
>  4. Migrate away from host 2. (many of those will get migrated back to 
>  host one)
>  
>  5. Reboot host two.
>  
>  6. Migrate away from host three.
>  
>  7. Reboot host three.
>  
>  etc.
>  
>  We have automated the migrate processes, so the total time is about 15 
>  minutes per server, including boot time, and no customer outage is realized.
>  
>  This is a very simple and strait forward procedure, with very little 
>  risk, that 'any monkey' can perform.  The definition of best practice, 
>  in my book.
>  
>  Ideas and suggestions are most welcome.
>  --
>  livecd mailing list
>  livecd(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/livecd