Nicolas Pitre wrote:
On Wed, 2 Feb 2011, Gordan Bobic wrote:
>> gordon is right about the SD/MMC card thing, but the "level 10" ones
>> can at least guarantee above 10mbytes/sec *read* capability. so
>> _yes_ to the SATA interface.
> The 10MB/s is _supposed_ to be for worst-case sequential writes. There
> is, however, no defined benchmark, and manufacturers are free to do
> their own testing. Most fail any sane real-world measurements of the
> specification.
>
> Just about every SD card I have seen apart from high end Lexar and
> SanDisk manage a whopping 1-3 4KB write IOPS. Team Class 10 32GB SD card
> is among those. So the class rating is pretty much completely
> meaningless for anything except (at most) digital camera use where you
> are sequentially writing large files to a FAT32 file system.
I'd suggest you have a look at the work being done by Arnd Bergmann on a
new device mapper target to overcome typical SD card misbehavior:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashD...
That sounds like a very complicated way to work around bad design using
a bodge. A much saner solution would be to use something like nilfs2
instead:
http://www.nilfs.org/en/
Or use something like "Managed Flash"
http://managedflash.com/index.htm
As far as I can figure it out, it converts all writes to a linear
write-ahead log (similar to what databases do, e.g. InnoDB), which is
always appended to. Then when there is idle time, you can commit those
transactions to where they actually need to be on the disk. Not really
ideal, but it's an option if nilfs2 isn't for whatever reason.
An interesting list, but basing such assumptions on the way the FAT32 is
laid out isn't necessarily sensible. Also remember that most embedded
devices (cameras, slates, phones) will blow away the partition table and
re-make it when they are told to blank/format the media. Android devices
certainly do. I have not yet seen any evidence that shows conclusively
that this makes a performance difference in the long-term.
Gordan