martin wrote: > On Wed, Mar 10, 2010 at 5:55 PM, Paul Fox <[email protected]> wrote: > > martin -- can you remind me of the use case for this flag? > > "I've right-sized my OS image and would like to have one less moving thing". > > Deployment teams can probably just set the "we're resized already" -- > so it doesn't actually require extra work...
you're assuming there needs to be such a flag. attempting to resize an already right-sized filesystem probably takes less time than checking a flag, so i wasn't going to add one if i didn't need to. but you're saying i need to, so i guess i will. but again: where should such a flag go? is there a precedent for such things? > > > - With some added bundles, there is the risk that our Journal-is-full > > > warning might appear on first boot; maybe it should not appear or use > > > a lower threshold until the "resize complete" flag is set. > > > > i'd say that if they're that close to filling the disk, the > > filesystem size should be made larger at build time. the only > > reason not to do that is if the target disk is very small, and if > > it's that small, then they've added too many bundles. > > Chris wants to generate a single image that is chock-full with as many > sample activities as we can fit. It is a veritable squeeze for the > sub-2GB image and will probably trigger the warning. i'm not sure you've changed my argument. you've just pointed out that i should have it with chris, too. ;-) > > And I forgot another To Do: add a big note in the release notes > explaining why the output of df is unreliable and variable until the > resize completes. It's bound to surprise a few people ;-) bah. it's a learning experience. paul =--------------------- paul fox, [email protected] _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
