[Arm-netbook] Must watch video of GK802

[jm]

On Fri, 2013-01-11 at 11:14 +0000, Gordan Bobic wrote:
> 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.

One device I know that got burned was a kingston.
But then again my detailed knowledge of SD card controllers 
is close to nil.

> >>  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/

Thank you for the link - I can see you spent time and money
to know what is good. Generally I aim for best price
and avoid anything with bad reviews. That is not a robust
method - because I treat them as throw away items
not to be trusted for long term storage of data.


> 
>  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.

I'm looking at the data from the link,
but I could not see where the difference
between reading contiguous data and random reads is published.


> 
> >>  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.

Sorry that is slightly different to what I was saying.
The OS for those devices is in the soldered down flash for those
devices. There is usually extra uSD to boot alternative OSes.

The GK802 has two uSD card slots in the video - one is internal and
hidden that contains the OS that ships with the product
as well the second accessible uSD card to boot your own OS.
http://www.youtube.com/watch?v=dHtQvGyV6Mk

So if you make a new OS, you simply put in your own uSD
into the hidden uSD reader, and then its completely
customized to your company! :-)
Normally, that is not considered robust because sdcards
are just not that reliable. But here they seem to think it is
and must have mitigated all their problems and ship
their device with their OS on an internal uSD card.