Re: 2Gb internal storage on N810

"lakestevensdental@verizon.net" <lakestevensdental@verizon.net> writes:

> While some express concern/fear about memory errors on flash cards,
> there seems to be little mention of such problems from n800 users who
> have been using replaceable flash cards for several years. So while
> there probably is some wall when these things may start to happen for
> n810s, it's still a bit out in the future. For n800s users, there's
> the simple fix of swapping a new card.

Easy fix for replaceable cards, but how about built-in 256MB flash
memory?


--
"Individual rights are not subject to a public vote; a majority has
no right to vote away the rights of a minority; the political
function of rights is precisely to protect minorities from
oppression by majorities (and the smallest minority on earth is the
individual)."
- Ayn Rand

Hi,

ext Alexandru Cardaniuc wrote:
>> While some express concern/fear about memory errors on flash cards,
>> there seems to be little mention of such problems from n800 users who
>> have been using replaceable flash cards for several years. So while
>> there probably is some wall when these things may start to happen for
>> n810s, it's still a bit out in the future. For n800s users, there's
>> the simple fix of swapping a new card.
>
> Easy fix for replaceable cards, but how about built-in 256MB flash
> memory?

As far as I remember correctly, on average it has enough write cycles
that you should be able to write to it *constantly* for tens of years.
I doubt the rest of device will last that long. :-)

Except for RSS, email etc refreshes which results are stored under
/home/ and operations for files on /home/MyDocs, there shouldn't be
much writes to it though. If you have Flash enabled in Browser, but
no memory card, the video streaming is buffered on that too.

Real reason for avoiding frequent writes / disk churn on rootfs is that
this would trigger JFFS2 garbage collecting much more frequently which
can *really* slow down your device:
https://bugs.maemo.org/show_bug.cgi?id=2615


The internal 2GB memory card in N810 has less write cycles than
the roots. Because it's larger, it can spread the writes over more
blocks i.e. wearing shouldn't be a problem for that either.

Btw. Personally, I wouldn't enable swap on it (from Control panel)
though, at least constantly, for following reasons (ordered from more
important to less important):
1. with constant swap file writes, it's much easier to
accidentally cause the card FAT file system to get corrupted
2. there's a performance slowdown (although swap allows running
some use-cases that wouldn't be otherwise possible)
(3. Flash wearing)

If you want swap, I would suggest a fast SD card with a separate
_partition_ for swap and some hacking on the device startup scripts
to support this.


- Eero

Eero Tamminen wrote:

> 1. with constant swap file writes, it's much easier to
> accidentally cause the card FAT file system to get corrupted
...

> If you want swap, I would suggest a fast SD card with a separate
> _partition_ for swap

AFAIK since version 2.4 of linux kernel, swapping to file no longer goes
via filesystem code at all and speed is similar/same to swapping to
block device directly. Kernel swapping code makes mapping for blocks
belonging to swap file on the beginning and then uses underlying block
device directly (both for speed and for deadlock prevention). If the
file is not heavily fragmented speed should be the same. Fragmentation
is visible in kernel log when swap file is enabled (number of extents).

As for corruption I'm not sure but I'd say it is not an issue too since
file is already allocated and filesystem code is not used when swapping.

Frantisek

Frantisek Dufka wrote:
> Eero Tamminen wrote:
>> If you want swap, I would suggest a fast SD card with a separate
>> _partition_ for swap
>
> AFAIK since version 2.4 of linux kernel, swapping to file no longer goes
> via filesystem code at all and speed is similar/same to swapping to
> block device directly.

more details here, 2.6 kernel is better
http://lkml.org/lkml/2005/7/7/326

Frantisek Dufka wrote:
> AFAIK since version 2.4 of linux kernel, swapping to file no longer goes
> via filesystem code at all and speed is similar/same to swapping to
> block device directly.

That is true but in this case, AFAIK, with the maemo control panel
you're building a swap file on a FAT32 file system. That would most
likely result in a different performance metric than if you built a swap
file on top of ext3 or used a raw swap slice. Someone please correct me
if I'm wrong, however, as I've considered partitioning up my own SD
cards. I do know that the I/O throughput varies greatly from card to
card which is why the high speed SDHC cards are more expensive depending
on the speed class. q.v. http://www.sdcard.org/developers/tech/speed_class

-Gary

On Thu, 23 Jul 2009, Gary wrote:

> Frantisek Dufka wrote:
>> AFAIK since version 2.4 of linux kernel, swapping to file no longer goes
>> via filesystem code at all and speed is similar/same to swapping to
>> block device directly.
>
> That is true but in this case, AFAIK, with the maemo control panel
> you're building a swap file on a FAT32 file system. That would most
> likely result in a different performance metric than if you built a swap
> file on top of ext3 or used a raw swap slice. Someone please correct me
> if I'm wrong,

You are wrong. A simplified version of what happens:
At swapon time, the kernel builds a table in RAM of where all the blocks
of the swap file are. Later during swap in/out the table is used and
filesystem is ignored. So filesystem might affect the time to run
swapon, which happens once at boot time, but does not matter to the swap
performance after that.



--
Matan Ziv-Av. matan@svgalib.org

Hi,

ext Frantisek Dufka wrote:
>> If you want swap, I would suggest a fast SD card with a separate
>> _partition_ for swap
>
> AFAIK since version 2.4 of linux kernel, swapping to file no longer goes
> via filesystem code at all and speed is similar/same to swapping to
> block device directly. Kernel swapping code makes mapping for blocks
> belonging to swap file on the beginning and then uses underlying block
> device directly (both for speed and for deadlock prevention). If the
> file is not heavily fragmented speed should be the same. Fragmentation
> is visible in kernel log when swap file is enabled (number of extents).

I think the file system (especially one as trivial as FAT) overhead is
trivial compared the Flash writing speed of the card.


> As for corruption I'm not sure

At least there were much more corruption reports from people who
had enabled swap than from ones that hadn't. (It's possible that
they are heavier users and therefore have more changes to mess
things up with accidental USB cable removal, taking card out while
it's still being used etc. But there were no re-producible use-cases
for verifying these things.)


> but I'd say it is not an issue too since file is already allocated
> and filesystem code is not used when swapping.

<speculation>
Whenever you do a write to a Flash based media, the data is written
somewhere else and the old block is GCed (with the HW API provided
by the memory cards kernel just doesn't see it). Also, I think
the Flash blocks could be larger than the ones used by kernel
internally for swap (4kB?) or the VFAT allocation units, or they might
not be aligned....?

So... It's possible that swap can affect the contents of rest of
the VFAT, especially if the swap file was made on a fragmented VFAT.
</speculation>


- Eero