[Arm-netbook] Must watch video of GK802

[jm]

On Fri, 2013-01-11 at 09:53 +0000, Gordan Bobic wrote:

> > This kind of thing should now be possible for all
> > these matchbox computers because of f2fs.
> > F2fs (flash friendly file system http://en.wikipedia.org/wiki/F2FS )
> > merged into the kernel that allows ordinary flash to be used
> > 
> > http://www.h-online.com/open/news/item/F2fs-flash-friendly-filesystem-integrated-into-Linux-1773746.html
> >
> > F2fs keeps writing files to new locations and then cycle
> > back to the beginning allowing even wear levelling.
> 
>  1) How is this different / better than nilfs2?

Thank you - sounds like I have to read up on nilfs2!

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


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


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

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

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