[svlug] SSD was: Slides from the GoLUG meeting

Rick Moen rick at linuxmafia.com
Fri Jun 3 01:34:11 PDT 2016

Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

> oh it does.
> https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt
> "CFQ has some optimizations for SSDs and if it detects a non-rotational
> media which can support higher queue depth (multiple requests at in
> flight at a time), then it cuts down on idling of individual queues and
> all the queues move to sync-noidle tree and only tree idle remains. This
> tree idling provides isolation with buffered write queues on async tree."

Predictably, you and I have a polite difference about interpretation of
that set of facts.  You see it as part of 'kernel can do a much better
job than I'.  I see it as 'CFQ code is clueful enough to get part of its
I/O-sorting logic out of the way on SSDs', which is gratifying but
obviously _not_ as good as just switching to a scheduler that _is_
appropriate on non-sequential, non-rotating media.

The point is, people who've studied this matter carefully say the Noop
and Deadline schedulers are simply better for such media, less impairing
of I/O, less wasteful of CPU cycles doing inapplicable things.  I see no
reason to doubt them, or to think that CFQ with some functions disabled
is better still.

Partly this reflects my bias for trimming away cruft, and towards
thinking that simple components with clear, stable interactions should
generally be preferred.  Partly it reflects my desire to check something
that comes strongly recommended by credible authorities, that is also
dead-easy to compare and test.  Which has lowest overhead?  Try each and
see.  If none has a significant advantage, personally I'd pick the one
with the simplest feature set, which is Noop.

What I cannot understand is why you think the quoted text shows that the
kernel can do a better job than you.  It doesn't show that at all, and
also good reasons why it's a doubtful assertion stand on their merits
irrespective of what that file says.

Maybe I'm missing something.  It definitely happens.  Not that this is
really worth debating.

> I don't know if it is enough to gain a significant performance advantage 
> over the once suggested deadline....

...so why wouldn't it be in order to test?

I really cannot understand this 'I read a kernel document saying the
default scheduler can figure out that it should disable parts of itself
on SSDs, therefore it must be the best scheduler for SSDs' logic.  I
mean, that just doesn't follow.

But what works for you is good.  Seriously.

> Considering performance and energy savings it makes a lot of sense 
> facebook, amazon, google and the like are moving to SSD and since now 
> they buy more gears than people buying desktop pcs I suspect it won't 
> take long to see full automagic tuning in Linux.

Meantime, my ol' buddy Daniel J. Bernstein says:  'This is Unix.  Stop
acting so helpless.'  ;->

> Is there anything worth considering other than sid?

To be honest, I haven't installed Debian for myself in ages because
'apt-get update && apt-get dist-upgrade' Just Works[tm] and makes
reinstallation unnecessary over many years.  However, my favourite
installer for Debian isn't any Official Debian image, but rather the
current progeny of the Sidux live CD project.

[Warning:  distro history recap ahead]

Sidux was an installable live CD based on sid and extremely compatible,
primarily adding the Sidux Project's package repo holding
sid-stabilising maintenance packages.

It was quite successful for a while, then the developers (mostly in
Germany) had an interpersonal blowup with some guy running the Sidux
Foundation.  The latter ended up walking away with the trademark and
name; the developers (who uniformly walked away from the foundation guy)
thus had to rename the project.  They chose the name Aptosid.  

Aptosid continued to publish quarterly updates of their live CD image
for some years, then there was another squabble, this time between two
factions of developers.  Some who wanted greater focus on desktop
computing left (a schism) and founded competing live-CD distro
Siduction, available with more DEs than Aptosid offered.

As often happens, something lately happened within the Aptosid Project, 
and they ceased issuing even overdue updates of the ISOs.  Distrowatch 
currently judges that project 'dormant', with its last release 3 years
ago.  Therefore, Siduction is now the surviving surviving Sidux fork.

I always like to have a live CD that has cutting-edge drivers and a full
set of administrative tools, for the sorts of things my old Linuxcare
Bootable Business Card project was good for, and later its offspring
Knoppix.  (Klaus credits the Linuxcare BBC as the source for many of the
key tricks he used in making Knoppix.)  Having a utility live-CD with a
very recent set of hardware drivers that is _also_ an excellent Debian
Sid installer makes it a two-for.

(I haven't actually sampled Siduction in quite a while, but I expect
it's a worthy succesor to Aptosid.)

Latest full release of Siduction (released New Year's Eve or
thereabouts) seems to have a 4.3.3 kernel, which is good enough --
though I'm also keeping an eye out for good live-CD distros with really
recent kernels.

More information about the svlug mailing list