[Arm-netbook] Must watch video of GK802

[Neal Peacock]

On 01/11/2013 05:56 AM, jm wrote:
> 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.

We had some like this before, the problem was the SD cards would slip
loose in shipping.  As many as 50% of the orders.  People were pretty
unhappy and most don't consider prying open the case to slip it back in
something they can handle.

If they tape it in or hot glue it or something it might work.  Also if
your devices are going to a hacker crowd like this mailing list you
probably wouldn't get as many complaints.
>
>
>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk