john wrote:
> > > but again: where should such a flag go? is there a precedent
> > > for such things?
> >
> > /.i-am-a-hidden-flag ?
>
> Safety would argue for doing the opposite:
>
> * Build the installation images to contain a file like "/.resize-root-once".
> * If that file is pres
> > but again: where should such a flag go? is there a precedent
> > for such things?
>
> /.i-am-a-hidden-flag ?
Safety would argue for doing the opposite:
* Build the installation images to contain a file like "/.resize-root-once".
* If that file is present
** Remove the file
** Sync the di
On Wed, Mar 10, 2010 at 6:27 PM, Paul Fox wrote:
> 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
Not only time / cpu burn but... I'd say it's less risky... once resize
completed with a sane
martin wrote:
> On Wed, Mar 10, 2010 at 5:55 PM, Paul Fox 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 i
On Wed, Mar 10, 2010 at 5:55 PM, Paul Fox 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 wo
martin wrote:
> On Wed, Mar 10, 2010 at 10:52 PM, Chris Ball wrote:
> > So, I'd say go ahead with this plan -- resize on first boot, but after
> > userspace is up and running (and if it fails, try it again until it
> > succeeds?). And, of course, we should test power loss during resize
> > s
On Wed, Mar 10, 2010 at 10:52 PM, Chris Ball wrote:
> So, I'd say go ahead with this plan -- resize on first boot, but after
> userspace is up and running (and if it fails, try it again until it
> succeeds?). And, of course, we should test power loss during resize
> some more.
Sounds reasonable
Hi,
> if we (or someone else :-) can convince ourselves that the online
> resize is really no less risky than simply using the filesystem
> normally (i.e., if power fails, will the ext3 journal fix things
> as well as it ever does?), then there's no real reason to do the
> resize wh
On Fri, Mar 05, 2010 at 08:55:26AM -0500, Martin Langhoff wrote:
> On Fri, Mar 5, 2010 at 1:39 AM, Paul Fox wrote:
> > i.e., if power fails, will
> > the ext3 journal fix things as well as it ever does?
>
> That would be my question... time to... yank that powercord!
I've got a desktop controlle
martin wrote:
> On Fri, Mar 5, 2010 at 1:39 AM, Paul Fox wrote:
> > i.e., if power fails, will
> > the ext3 journal fix things as well as it ever does?
>
> That would be my question... time to... yank that powercord!
i've only tried it once. when the machine rebooted, i was left with
a fil
On Fri, Mar 5, 2010 at 1:39 AM, Paul Fox wrote:
> i.e., if power fails, will
> the ext3 journal fix things as well as it ever does?
That would be my question... time to... yank that powercord!
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting que
james wrote:
> On Fri, Mar 05, 2010 at 01:39:23AM -0500, Paul Fox wrote:
> > resize drags performance way down. but "nice -19 resize2fs
> > /dev/mmcblk0p2" only adds about 25% to the runtime (~50sec vs.
> > ~40sec),
>
> Consider ionice for reducing the I/O priority of the task.
> e.g. io
On Fri, Mar 05, 2010 at 01:39:23AM -0500, Paul Fox wrote:
> resize drags performance way down. but "nice -19 resize2fs
> /dev/mmcblk0p2" only adds about 25% to the runtime (~50sec vs.
> ~40sec),
Consider ionice for reducing the I/O priority of the task.
e.g. ionice -c3 resize2fs ...
Also, did
i wrote:
> i'm moving a discussion-in-progress to the devel list. as
> background: because XO-1.5 uses an internal micro-SD for mass
> storage, we don't know the exact size filesystem to create at
> image build time. not only do we ship laptops with (currently)
> 2G and 4G cards, but cards
[ some of these are repeats from the private discussion]
On Thu, Mar 4, 2010 at 2:06 PM, Chris Ball 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 p
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 f
i'm moving a discussion-in-progress to the devel list. as
background: because XO-1.5 uses an internal micro-SD for mass
storage, we don't know the exact size filesystem to create at
image build time. not only do we ship laptops with (currently)
2G and 4G cards, but cards of a quoted size from di
17 matches
Mail list logo
