[ some of these are repeats from the private discussion] On Thu, Mar 4, 2010 at 2:06 PM, Chris Ball <[email protected]> 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 -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
