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.
Is this real rotational latency, or normalized? I think that the avg
seek time is usually a bit more predictive of how well we do with the
worst case load (fsck).
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.
This is changing - they have various ways of getting them much closer
together. On the other hand, a USB flash drive is much slower than a
high end SSD which can hit 20,000 IOPS.
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
If we have access to the parts, we will try to get them to self tune
given whatever we can grab.
ric
--
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
