Re: [DO NOT APPLY] sd take advantage of rotation speed

[Ric Wheeler <rwheeler@redhat.com>]

Grant Grundler wrote:
> On Mon, Jul 28, 2008 at 7:31 AM, Martin K. Petersen
> <martin.petersen@oracle.com> wrote:
>   
>>>>>>> "Ric" == Ric Wheeler <rwheeler@redhat.com> 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