resizing rootfs to fit the disk

[Martin Langhoff]

[ some of these are repeats from the private discussion]

On Thu, Mar 4, 2010 at 2:06 PM, Chris Ball <cjb at laptop.org> wrote:
> 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.

>From a deployment-support point of view, *any* boot-time resize we do
must be complemented by a utility to resize the .zd image .

A deployment team knows what disk size they have (even if they have
miniSD disks from various vendors, they can find out the lowest common
denominator), and the advantage of skipping the resize step can be
important... specially if we don't do partitioning.

>   >     - several people think we should separate the base OS from
>   > the user data, by giving /home a separate partition.  how would
>
> I don't think we should add this feature into the mix yet

I don't like partitioning either --

cons:

 - We don't have a good resize plan: LVM+ext3 resizes won't work
"online", so we'll have to do it from OFW or from the initramfs. And
LVM+ext3 resizes are fragile as hell, specially in the face of
powerloss.

 - Will break systems when one partition is full, with little clarity
as to what's happening. For example, yum can consume a ton of
diskspace in /var/cache/yum to run an upgrade that leads to a
similar-sized OS footprint.

 - Having a tight / breaks _both_ olpc-update and yum. It effectively
cuts all upgrade options except fs-update / nandblast.

 - Our OSs are effectively "OS+Apps" -- and the "Activities" part of
it lands in /home, so the desired "protect /home/ when upgrading via
fs-updatte / nandblast" isn't actually achieved. Or will at least need
extra elbow grease and storage in / (and some bundles can be huge -
ie:Wikipedia.xo).

pros:

 - makes "first-boot resize" super fast and resilient -- because it
becomes "firstboot mkfs /home"

 - it could protect /home during upgrades if... am... lots of other
things were solved  :-) -- _if they can be solved so that they work
with a tight / partition_.

In summary, I suspect the main desired benefit of a partitioned /home
is too hard to reach.

>   >     - we could put resize-at-boot code in place (with or without
>   > a splash screen), and ship multiple, somewhat undersized images.
...
...
>   >     - we could make the resizing a manual step, from the control
>   > panel or elsewhere.  we sort of need a simple disk management
>   > screen anyway.

Valid ideas. I think it would be smart to separate our use cases --

 - Medium-to-large deployments -- give them the ability to make
nearly-right-sized images easily, so nandblasting and usb-based
reflashing don't require a slow & brittle resize-on-first-boot.

 - Small deployments, developers, testers, enthusiasts, demo machines
-- can handle slightly undersized images without ever worrying about
it. For them, provide a commandline (`touch /resizeme`?) that on boot
triggers the "on-boot-resize" codepath -- to be used by advanced
enthusiasts/testers and smallish deployments (that often have some
geek wisdom but aren't hardcore enough to make their own OS images).

For completeness, an undercurrent here is "mid/large deployments must
have an XS performing backup of the Journal data". Yes they should,
I'll add my signature to the petition!

But fs-update-and-restore-your-journal-data can't be the only way to
upgrade your XOs. Removing options (yum, olpc-update) won't be popular
with people in the field.

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff