On Thu, 2008-07-31 at 14:00 -0700, Grant Grundler wrote: > 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. > Could performance patterns be encoded in some sort of per-product data structure ala the scsi_static_device_list? Andrwe -- 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
