[Ksummit-2008-discuss] Suggested topic: possible

Ric Wheeler ricwheeler at gmail.com
Thu Aug 7 05:04:56 PDT 2008


James Bottomley wrote:
> On Wed, 2008-08-06 at 13:55 -0700, Arjan van de Ven wrote:
>   
>> James Bottomley wrote:
>>
>>     
>>>> I assume that the return from request-size-maximisation on SSD is
>>>> better than the return on seek-avoidance.
>>>>         
>>> Not necessarily ... larger transfers are still better because of erase
>>> block considerations, and they do help flash a lot.
>>>       
>> they help todays flash . Future flash likely overcame this issue.
>>
>>     
>>>> I assume that we can beneficially throw away (ie: bypass) a large part
>>>> of the filesystem and block layer seek-minimisation and
>>>> request-size-maximisation code when the backing device is SSD.
>>>>         
>>> One of the sad facts of flash is that writes are much more expensive
>>> than reads, so quite a lot of work done on the ioschedulers is still
>>> valid (even if it was originally aimed at rotating media).
>>>       
>> even this is questionable on future flash ;)
>>
>> Today writes tend to be about 2x more expensive on the better SSDs.
>>
>>     
>>>  I suspect until
>>> we start playing with the real things, we won't have any idea what needs
>>> tuning or replacing in the elevators.
>>>       
>> just because YOU haven't seen them doesn't mean nobody else saw them.. please don't dismiss
>> optimizations done by the people who have just because you haven't seen the devices.
>>     
>
> Heh, I haven't even seen Gen I SSDs (and neither have most people) let
> alone Gen II.
>
> I didn't dismiss any optimisations ... I merely said that speculating
> about how we should alter the OS based on chinese whispers (or what I
> saw in today's slideware) isn't a good methodology.  We need to play
> with these things in the current Linux environment before we can work
> out what needs to be fixed up or tuned for them.  All of the speculation
> tends to come back to properties they may or may not exhibit in the
> wild.  As Ric has already pointed out, modern high end arrays with
> Gigabytes of cache behave essentially like SSDs from the write
> perspective because of the huge buffer they provide to the spinning back
> end; the current elevators cope with them just fine.
>
> James
>
>
>   

We have been buying (and collecting from willing partners) real devices 
so we can try and get actual run time on real parts and tune code 
accordingly.

On the array side, it is interesting to note that it is fairly normal to 
run with the noop elevator (not CFQ or AS) since the arrays handle 
writes at least much better than we can on the host side.  Unlike real 
SSD, arrays are at their best with writes (sequential or random) while 
SSD's are best at reads.

ric



More information about the Ksummit-2008-discuss mailing list