[svlug] SSD was: Slides from the GoLUG meeting

[Ivan Sergio Borgonovo]

On 06/02/2016 04:33 PM, Rick Moen wrote:

> Switching the kernel to use the Noop or Deadline scheduler to process
> kernel threads touching the SSD makes SSD access faster and reduces
> wasted CPU load -- because pretty much all of the complicated I/O
> optimisation algorithms in the kernel's default CFQ scheduler are
> inapplicable and merely slow down I/O and waste CPU time.  The reason
> you make the change is _not_ to 'reduce SSD wear', but rather to
> eliminate pointless waste.

It seems to be part of the past. When I bought my 850 PRO I was happy 
enough I didn't have to bother about wearing so I didn't split my stuff 
over platters and ssd. Having /var and ~/ on ssd made a so BIG 
improvement on performance I was already in the "I don't care, it just 
works" mood. But before deciding I didn't have to worry about wearing I 
spent a bit of time googling and I remember I read something in the line 
"now the kernel knows and it can do a much better job than you".

>> Wearing SSD seems to be a non issue as well, for a "home" use so, moving
>> /var or "things that change" including your /home is just going to slow
>> down your system (and pretty much).

> No, that depends on where you move them _to_.  E.g., moving highly
> dynamic things to tmpfs filesystems, if they're relatively small, is
> likely to speed up your system because, even though SSDs are quite fast,
> RAM is significantly faster still -- especially on writes.

On my system the sensible things have smart default and they have been 
such for some years I think and they have been moved there for everyone, 
not just for people using SSD.

> The argument for keeping (specifically) /var on a hard disk (if you have
> a hard disk in addition to an SSD) is less a matter of '_need_ to' than
> it is 'keeps off the SSD the worse of the file-rewriting activity that
> generates write-amplification and hastens the need for a TRIM cycle'.

> You don't want to bother doing any of the optimisations I discussed?
> OK, my blessings upon that, and you didn't ever 'need to' do them --
> they merely would have helped in various ways:  increased system
> performance, slowed write amplification effects, etc.

My point is that unless you're doing something really exotic newer SSD 
seems to be safer than HD, linux kernel is way more aware about how they 
work and in no more than a couple of hw iteration everything is going to 
be abstracted away.
"Long warranty" is still an indication of how much the manufacturer is 
confident about its products and if an enterprise grade HD with platters 
comes with a 5 years warranty and an SSD comes with 10... I may not 
trust the numbers but the difference still say something.
And yeah it may mean they have higher margin on SSD than HD so they are 
more willing to replace your SSD than your HD... but still...

Of course there are people that have to be very conservative about their 
choices and even the fact they know better when and how HD will fail 
will make them a better choice than SSD that still are a "moving 
target". Not to mention cost differences if you've to store tons of data.

Having a precise idea about failure rates may have a huge economical 
impact on maintenance if you've a huge amount of storage to manage, but 
actually you can have a precise and useful idea if you have a huge 
amount of storage to manage and cost/Gb difference between platters and 
SSD is still pretty high.
Mere mortals should just be happy that finally SSD possibly surpassed 
platters in reliability and that shouldn't come as a surprise and it is 
a far simpler explanation than thinking that Samsung is still happy to 
replace your SSD.

>> If I had to be concerned of something I'd be concerned of the
>> manufacturer firmware.

> Me too.  But those other things I can optimise with trivial effort.
> With manufacturer firmware I can only reflash to the latest and hope
> they didn't screw up.

>> Firmwares are reasonably complicated and offer a
>> lot of "tuning" space and they are strictly dependent on the underlying
>> solid state technology and there things don't seems to be settled.
>> Complicated moving things tend to be buggy.

> This is true, but...

>> So theoretically we should be near to forget everything about SSD tuning
>> at higher layers, practically:

> This doesn't follow from it.

Yeah of course if you read: you don't have to bother about tuning 
because SSD are a moving target it doesn't make sense.
But I meant that since solid state technology is near to a point to make 
SSD even more reliable and *consistently* faster than platters and the 
kernel is more aware of the underlying hardware we're very near to the 
point (or we are already there?) where you shouldn't bother about tuning 
but rather about firmware bugs.

But of course not everyone is running sid and just bought a brand new 
SSD... so your guideline are absolutely valuable.

I've an older Samsung 830 and there things are split between SSD and 
platters and mostly for "historical" reasons the scheduler is set to 
deadline even if maybe it doesn't make any difference with newer kernel.


and yeah I'm sorry I may repeat stuff you've already said but I bet I'm 
not the only one on the list that wasn't at your speech so they may be 
still useful to many.

If I could I would have been there, I oscillate between reckless 
behavior and paranoia to get the worst of both world to build up 
experience ;)

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it