On Mon, Jul 28, 2008 at 7:31 AM, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: >>>>>> "Ric" == Ric Wheeler <rwheeler@xxxxxxxxxx> writes: > > Ric> One other thought - is there a way to give non-rotational devices > Ric> also some indication of latency? (FLASH is slower than enterprise > Ric> SSD is slower than DRAM ramdisk for example)? > > The current SBC draft only distinguishes between rotating media > speeds. There is only one classification for non-rotating media in > the block device characteristics VPD. > > For a mechanical disk drive the rpm isn't a terrible gauge for > performance. But for a solid state device I think it will be hard to > define a similar universal metric. rpm isn't a great gauge of performance either since the perf is a function of rpm * bit density. > Ignoring SLC vs. MLC for a moment I think it's also safe to predict > that the enterprise drive of today will be the consumer drive of > tomorrow. > > Maybe the ssd device could export the anticipated command response > time for a request that matches the Optimal Transfer Length field in > the block limits VPD? erase and/or write times could be exported as well somehow for SSDs if the FS (or other higher layer that wants to know) can't avoid garbage collection and erase cycles. I was just told today that flash devices have 10x higher write time than read time. erase is another order of magnitude higher. This doesn't include any garbage collection overhead. I think new file systems should be tuned to work with SSDs before we worry so much about the differences between SSDs/flash technologies and vendors. And then prescribe a different FS for different storage technologies. This avoids the "layering violations" discussion and helps keep the FSs (testing and developement) substantially simpler. grant -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
