resizing rootfs to fit the disk

[pgf at laptop.org]

i'm moving a discussion-in-progress to the devel list.  as
background:  because XO-1.5 uses an internal micro-SD for mass
storage, we don't know the exact size filesystem to create at
image build time.  not only do we ship laptops with (currently)
2G and 4G cards, but cards of a quoted size from different
vendors vary in useable size (by quite a bit).  so we currently
build otherwise-identical 2G and 4G images, both undersized to
accomodate vendor variations.  we'd prefer not to have to do
this -- it would make the builds easier, and would let users
use any size card they'd like.

thus far in our story:

    - several people think we should be trying to do a full
      filesystem resize at boot -- advantage is that we can ship
      a single image, and have it work on all SD cards.  it would
      require a new 'please wait' splash screen (which should be
      a good one, with seamless transition -- this may be the
      first user experience), and adds some risk to the boot
      process.  first linux boot happens at the factory for new
      laptops, but in the child's hands in most deployment
      scenarios (where nandblaster or usb sticks are used).

    - several people think we should separate the base OS from
      the user data, by giving /home a separate, variable,
      partition.  we would then build images to match a fixed
      root fs size.  would we size the root fs?  having a hard
      constraint that we must fit into wouldn't be bad thing, as
      long as we don't pick an unreasonably small value, and as
      long as there's a fallback plan when we blow it. 
      olpc-update may double the space requirement in the worst
      case, right?  i've never used LVM -- could it help make the
      boundary moveable?

    - we could put resize-at-boot code in place (with or without
      a splash screen), and continue shipping multiple, somewhat
      undersized images.  any image could be used on any bigger
      SD card, and the right thing would happen, but in the usual
      case where an image is correctly sized, the resize time
      wouldn't take too long.  perhaps we could suppress the
      splash screen for resizes that we think won't take too
      long?

    - we could make the resizing a manual step, from the control
      panel or elsewhere.  we sort of need a simple disk
      management screen anyway.

(btw, regardless of our decision, this is clearly more than a simple
bug fix.)

paul
=---------------------
 paul fox, pgf at laptop.org