anonymous (no@thanks.com) on 1/6/09 wrote:
---------------------------
>I think Linus is a bit off the pace in embedded systems - he forgets that to have
>a comtroller do that adds cost there when the 'main' cpu can do it easily enough
>- but in more normal systems, IDE sector remapping and flash write leveling are
>not dissimilar in how they should/should not be exposed.
>
>Now, of course this is why there are 'RAID' type SATA drives, because they return
>faster and spend less time trying to remap (as that can KILL performance) and I
>see the same opportunity for flash - the performance cost of write leveling could
>be ugly in a few rare cases, so perhaps there should be an api to turn it off and then have to do it yourself, perhaps..


The embedded market probably breaks into two segments - the ones needing only a chip or two worth of flash, and the bigger systems. The former probably will want to do wear leveling (and whatever) themselves to minimize hardware costs (and those probably have relatively low write rates to begin with, so they don't have to do all that great a job of it), and the bigger ones can use "normal" drives. In the former case you're not really looking at standard interfaces anyway (IOW, it's not going to be SATA if you have a sing chip of flash), and not typically field replacability either, so some weirdness is acceptable.

But I don't see any reason why you can't (and wouldn't) expose the lower level interface for select folks. And the big disk array vendors are a perfect example - they do more than the normal amount of low-level mucking about even on conventional disks. Although in that case you have to wonder if it becomes enough easier to actually supply then with (almost) controller-less drives or flash chips directly, that big drive arrays stop being built from "complete" commodity drives.