Sorry, should have explained myself better, as I was also talking
about memory speed and not size, this time.
Ahh, if you wrote about memory size then never mind my comments. :)
Thing is, most flash controller implementations are crap, and it will
probably be the case with the one in Gen 1.5. I'm quoting 0.5MB/s in
*random writes* to the file system, nothing to do with compression.
Most decent SSDs can write at last 1MB/s with some topping 2MB/s, in
random patterns, sequential is about 150MB/s+. Sequential is not the
problem when using SD cards or most USB drives, random writes is, when
you're trying to have an OS on it.
The best drives around, from Intel, can do 20+MB/s in random writes.
Most SSDs on the market are based on J-Micron controllers that can do,
at most, 0.04MB/s in random writes. This causes the system to
frequently stall when some app is performing heavy writes to arbitrary
locations. Random reads are mostly very fast with every type of flash
you can get.
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=25
<http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=25>
0.5MB/s in RR should be enough to avoid most stalls.
I hope that Mich Bradley will educate us but it seems to me that the
hidden eraseblock handling can be the problem with those devices (and if
it is true then compression will not help it either). It seems to be
that some tests are required with physical hardware, a paper processor
will not be enough... :)
Are there any plans using UBIFS?
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
