SSDs vs elevators (was Re: cap on writeback?)

[Raymond Jennings]

On Tue, Mar 26, 2013 at 9:46 AM, Arlie Stephens <arlie at worldash.org> wrote:
> On Mar 25 2013, Valdis.Kletnieks at vt.edu wrote:
>>
>> Just for the record, most of my high-performance stuff runs best with
>> the noop scheduler - when you're striping I/O across several hundred disks,
>> the last thing you want is some some single-minded disk scheduler re-arranging
>> the I/Os and creating latency issues for your striping.
>>
>> Might want to think about why there's lots of man-hours spent doing
>> new filesystems and stuff like zcache and kernel shared memory, but the
>> only IO schedulers in tree are noop, deadline, and cfq :)
>
> Interesting. I'd have expected, naively, that when dealing with SSDs -
> and their delightful habits of rearranging data under the covers,
> suddenly introducing delays, as well as their desire to have reads
> grouped away from writes (RWRWR == slower than RRRWW if I understand
> correctly) there'd be work to be done at the IO scheduler layer, not
> just at the file systems layer, to get the best performance out of SSDs.
>
> For the record, my own attempts to get performance out of SSDs have
> been productive of nothing but pain. I was, however, trying to do this
> _without_ kernel mods, and on FreeBSD rather than linux.
>
> --
> Arlie

If I had to guess, firmware housekeeping is considered the same as how
rotational media buffers and queues and caches behind the sata bus,
namely that "the device has a mind of its own"

Often this is seen as an argument against allowing the media to do any
serious caching and instead let the kernel's page and buffer caches
handle it.

Oddly it's been said that disabling write caching on the device can
improve performance by preventing the drive heads from sneaking away
from where the block driver parked them..