from the department of opportunity-bearing-tradeoffs...
For XO-1.5 we build our OS images to be a bit "short" of the stated SD
card size, because different SD cards placed in mfg vary in exact
size.
That means we always have a bit of space left over. We could add an
init script that sets up a sma
Assuming OLPC isn't using TRIM support on the SD cards, writes to the
swap space are indistinguishable from writes to any other space on the
card. That means that writes to the swap "partition" could
potentially corrupt other data on the card, especially if it occurs
less than 30s before removal o
On Mon, Nov 22, 2010 at 11:32 AM, C. Scott Ananian wrote:
> just as well. Our superstitions about OLPC's no-swap configuration
> may well prove to be similarly unfounded.
Just to clarify -- side-to-side comparison in the past have shown a
significant improvement. We did get a specially bad-behav
On 22 November 2010 16:41, Martin Langhoff wrote:
> Just to clarify -- side-to-side comparison in the past have shown a
> significant improvement. We did get a specially bad-behaving kernel in
> our F7 builds in that regard, but even F9 builds have shown it to be
> better.
That was an XO-1 compar
As my own clarification: I wasn't dismissing possible performance
improvements (of any kind). I was just commenting on the old "lockup"
bugs, saying this might not actually be related to no-swap-space,
although it's possible memory pressure exacerbates the problem. For
performance issues, you hav
> Downsides
> - Increased SD card wear
For about two years now, I've been defining a swap partition on the
(external) "permanent" SD card I use with my XO-1 systems. So far, I
have never experienced any problems with that setup.
The advantage is to relieve "memory pressure". In particular, I am
On Mon, Nov 22, 2010 at 2:21 PM, Mikus Grinbergs wrote:
>> Downsides
>> - Increased SD card wear
>
> For about two years now, I've been defining a swap partition on the
> (external) "permanent" SD card I use with my XO-1 systems. So far, I
> have never experienced any problems with that setup.
A
On Mon, Nov 22, 2010 at 11:03:26AM -0500, Martin Langhoff wrote:
> - Slightly longer first boot
> - Slightly more fragile first boot (can we make it failsafe?)
There's no reason to do this during boot. The new partition can be
added after boot, followed by mkswap and swapon.
--
James Cameron
> Assuming OLPC isn't using TRIM support on the SD cards, writes to the
> swap space are indistinguishable from writes to any other space on the
> card. That means that writes to the swap "partition" could potentially
> corrupt other data on the card, especially if it occurs less than 30s
> before
On Mon, Nov 22, 2010 at 6:43 PM, Mikus Grinbergs wrote:
> If "indistinguishable" is true, then there is as much wear to the SD
> card from one file-block written as there is from one swap-block
> written.
Yes.
> I have no measurements whatsoever - but my gut feel is that
> the majority of my SD
On Mon, Nov 22, 2010 at 05:43:18PM -0600, Mikus Grinbergs wrote:
> > Assuming OLPC isn't using TRIM support on the SD cards, writes to the
> > swap space are indistinguishable from writes to any other space on the
> > card. That means that writes to the swap "partition" could potentially
> > corru
>> Note: I'm using an external SD card. So if it fails before the OLPC
>> itself fails, I can at reasonable expense replace this swap device -- I
>> don't have to plan for a definite wear lifetime.
> Are you making regular backups?
Anything that needs to be preserved is copied to a central hard-
On 11/22/2010 07:20 PM, James Cameron wrote:
>> Also, I'm not familiar with "evil keepout time". But note that on the
>> new XO-1 F14 build, the "shutdown" time-lapse is only a few seconds.
>> If actually 30s are needed to keep the SD circuitry happy, perhaps a
>> delay (and a Release Notes expla
On 11/24/2010 09:53 AM, Richard A. Smith wrote:
> or so from the last write. I recommend you do hard power offs little as
> possible. Suspend/resume also should be disabled.
My statement is not 100% accurate. The external SD card can remain
powered in suspend so you don't have to disable sus/re
On Mon, Nov 22, 2010 at 4:41 PM, Martin Langhoff
wrote:
> On Mon, Nov 22, 2010 at 11:32 AM, C. Scott Ananian
> wrote:
> > just as well. Our superstitions about OLPC's no-swap configuration
> > may well prove to be similarly unfounded.
>
> Just to clarify -- side-to-side comparison in the past ha
On Mon, Nov 22, 2010 at 7:21 PM, Mikus Grinbergs wrote:
> > Downsides
> > - Increased SD card wear
>
> For about two years now, I've been defining a swap partition on the
> (external) "permanent" SD card I use with my XO-1 systems. So far, I
> have never experienced any problems with that setup.
BTW, the card is a Sandisk 4GiB Class 2, bought used on eBay. First one
bought for installing OSs, going stronger where others have failed with a
lot less use. Approximately 1GiB is free, not touching the NAND for anything
other than testing new XO OS releases.
Tiago
On Mon, Dec 6, 2010 at 12:25
That's strange, wherever I have used flash memory to serve as boot drive,
the kernel/userspace waits for the writes to be complete before powering
down. I have not experienced corruption that looks anything similar to
what's described. So the software is thinking it has written it but it
doesn't?
Hi,
> That's strange, wherever I have used flash memory to serve as
> boot drive, the kernel/userspace waits for the writes to be
> complete before powering down. I have not experienced corruption
> that looks anything similar to what's described. So the software
> is thinking it ha
On Mon, Dec 6, 2010 at 1:04 AM, Chris Ball wrote:
> Hi,
>
> > That's strange, wherever I have used flash memory to serve as
> > boot drive, the kernel/userspace waits for the writes to be
> > complete before powering down. I have not experienced corruption
> > that looks anything similar
On Mon, Dec 06, 2010 at 12:30:52AM +, Tiago Marques wrote:
> That's strange, wherever I have used flash memory to serve as boot
> drive, the kernel/userspace waits for the writes to be complete before
> powering down. I have not experienced corruption that looks anything
> similar to what's des
21 matches
Mail list logo
