[svlug] SSD was: Slides from the GoLUG meeting
Ivan Sergio Borgonovo
mail at webthatworks.it
Thu Jun 2 10:33:16 PDT 2016
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
More information about the svlug
mailing list