resizing rootfs to fit the disk

[Paul Fox]

i wrote:
 > 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:

i thought of one more possibility, later this afternoon, which is
pretty interesting.  if we (or someone else :-) can convince
ourselves that the online resize is really no less risky than
simply using the filesystem normally (i.e., if power fails, will
the ext3 journal fix things as well as it ever does?), then
there's no real reason to do the resize while the laptop is still
booting.  we can just as easily do it _after_ it has booted,
while it's in use.  i've tried this -- left on its own, the
resize drags performance way down.  but "nice -19 resize2fs
/dev/mmcblk0p2" only adds about 25% to the runtime (~50sec vs. 
~40sec), and keeps the system reasonably responsive in the
meantime.  more testing, and conversations with ext3 experts,
would clearly be needed before thinking of commiting to this.

paul

 > 
 >     - 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
 > _______________________________________________
 > Devel mailing list
 > Devel at lists.laptop.org
 > http://lists.laptop.org/listinfo/devel

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