resizing rootfs to fit the disk

[Chris Ball]

Hi,

   >     - 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.  requires a
   > 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).

I still like the flexibility here, but I suspect you're right that the
support cost from doing a long resize at the first boot in front of a
user (and having corruption result from a poweroff) will be too high.

   >     - several people think we should separate the base OS from
   > the user data, by giving /home a separate partition.  how 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?

I don't think we should add this feature into the mix yet, because
I disagree that it wouldn't be bad -- we don't know whether a user
prefers to create their own content in /home, or mainly to install
new applications with yum, so we shouldn't decide for them by setting
an artificial size on / vs. /home that they can't change easily.

(If there were a way to have yum and rpm install to /home, that might
get around this objection, but I don't think it's possible.)

I'm not sure that LVM helps here:  I don't think it can do online
shrinking, so it would have to queue up a boundary change for the next
reboot.  We'd then have to teach OFW about LVM, and make OFW image
reflashes honor the LVM boundary else they'll stomp over /home, which
is what we were trying to avoid.

   >     - we could put resize-at-boot code in place (with or without
   > a splash screen), and ship 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?

This is sounding more likely.  Perhaps I should kick off a build with
both images ~100M smaller, so we can see exactly how long it takes to
do a near-resize?  Do we think ~50M smaller for each would be enough
to cover all of the 2G and 4G SD cards we might run into?

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

I'm not sure what to think about a disk management control panel;
I think our mental model of control panel users should approximate
"will press control panel buttons with no particular rationale", so
we should keep any dangerous or non-revertable actions away.

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

Yeah, agreed.

Thanks,

- Chris.
-- 
Chris Ball   <cjb at laptop.org>
One Laptop Per Child