[Arm-netbook] Must watch video of GK802

[Gordan Bobic]

 On Fri, 11 Jan 2013 10:56:54 +0000, jm <joem at martindale-electric.co.uk> 
 wrote:

>>  nilfs is fully log structured and always appends
>>  to the end, with a garbage collection thread that
>>  starts from the head of the log (block device), and writes
>>  the de-garbaged data back to the tail of the log.
>>
>>  Is f2fs more clever and less write-intensive (due to
>>  the nature of nilfs2's garbage collection)?
>
> f2fs - I think it gets all its speed because there
> is no defragging until it reaches back to the beginning
> at which point it is forced defrag.

 That's not really that much better than nilfs2. That just
 doesn't bother garbage collecting until free space drops
 below a settable threshold. Garbage collector thread
 is also throttlable and nice-able (and ionice-able, but
 that only works on CFQ which is largely unfit for any
 purpose these days).

>>  Either way, this is by no means a pre-requisite for
>>  using such devices. Many existing ARM machines
>>  have been happily running off eMMC and SD devices long
>>  term without any issues regarding media wear-out.
>
> Correct if its only reading. But general purpose
> Linux needs to read and write.

 My SheevaPlugs do plenty of writing - they are used as
 general purpose servers. I use a Toshiba AC100 daily
 as a general purpose laptop. SD/eMMC wear really isn't
 as big a deal as you might think.

>>  My SheevaPlugs run off an SD card, and have been for
>>  at least a couple of years without any issues,
>
> I have 2 but I run general purpose Linux and have
> ruined several flash drives despite being ext2 formatted.
> I would log into them and set it on download a large
> number of files. One file at a time not a problem, but I think when
> running parallel downloads seems to be the time when it kills it.

 My guess would be that you have been using particularly
 bad flash media. Pretec USB sticks are known to be
 particularly useless (killable in a few hours using a
 basic iozone test). But most have been fine (Kingston
 controller based USB sticks and SD cards,
 SanDisk MLC and Integral SLC SD cards, etc. I have
 a number of servers using them as primary storage and
 none have exhibited problems after a couple of years
 of use.

>>  as
>>  have my Toshiba AC100s. It's really not a problem.
>>  Performance on random-writes is a much bigger issue,
>>  which is one place where something like nilfs2 helps
>>  a great deal by making all writes always linear,
>>  this making your random write MB/s the same as your
>>  linear write MB/s. Reads are extremely quick on
>>  SD cards regardless of whether they are sequential
>>  or random
>
> Random is slower because the SDCard registers have to
> be set up to start reading at a new address.
> Sequential is fast because one read after another
> can be instigated without needing to send in
> an address for each read.

 See my benchmarks here:
 http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-cards-cf-cards-usb-sticks/
 (link at the bottom)

 Most SD cards manage at least 1000 IOPS (4KB blocks)
 on random reads, some over double that. If that isn't
 fast enough you must have the fastest ARM machine in
 the world.

> Writes have similar problem - but doubly slow because writing
> is inherently a slower process.

 See the benchmarks at the link above. Random-write
 performance on generic flash media (proper SSDs excluded)
 is appallingly slow. Random writes are a major
 performance issue for SD cards. Random reads are fine.

>>  so potential de-linearization of them
>>  isn't problem.
>>
>> > The great thing is that you can now yank out the OS
>> > and put a new OS in seconds. No way to brick a device.
>>
>>  There are several other devices that work this way.
>
> My ignorance - I haven't yet come across any common tablets
> or devices that have uSDCard for its OS. Hence the excitement.

 I seem to recall the Via APC does the same thing. The Genesi
 Efika MX Smartbook by default checks the uSD card slot for an
 OS first, IIRC, and only then tries to boot off internal CF
 (soldered on, non-removable, sadly) I'm sure there are others
 with similar features.

 Gordan