svn commit: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys

[Poul-Henning Kamp]

--------
In message <CANCZdfoWiD9zsBJE8U+PM5LyLSKLgQu9m2pvdkUFbuccv_q-Qg at mail.gmail.com>, Warner Losh writes:

>I never enabled it because I never had a good car size as the default. I'm
>guessing  it's somewhere on the order of 2 times the queue size in
>hardware, but with modern drives I think phk might be right and that
>disabling disksort entirely might be optimal, or close to optimal.

I think that is a given for SSDs.

For disks I fear it would be a model-by-model determination.

The situation is quite different for "traditional" and shingled
drives for instance, or if, God forbid, the rumours are true and
we'll see IBM3380-style dual head assemblies in the market again.

I guess the kernel could turn the disksort on/off a few times and
only leave it on if it improves things.

But first, Somebody Should™ benchmark to see if disksort *ever* is an
improvement on contemporary disks.

Poul-Henning

PS: If somebody really want to improve disk- and ssd- performance, the
low-hanging fruit is to write a log-structured storage engine under
UFS, to make life easier for flash-adaptation layers and shingling
drives.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.