resizing rootfs to fit the disk
cjb at laptop.org
Thu Mar 4 14:06:40 EST 2010
> - 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.)
Chris Ball <cjb at laptop.org>
One Laptop Per Child
More information about the Devel