[arch-general] Optimising ssd setup?

[Karol Babioch]

Hi,

Am 07.01.2013 17:24, schrieb Mike Cloaked:
> but I am unclear if this happens automatically or
> not when setting up GPT partitions with gparted?

These days all of this happens automatically. Personally I'm not using
gparted, but I would be surprised, if there are still problems in
regards to proper alignment.

> Also I have been seeing various bits of advice about ensuring that
> excessive writes are avoided by using a non-default IO scheduler

To be honest, I don't see why a IO scheduler would make much of a
difference here. The scheduler is supposed to decide, which block should
be written and/or read next.

The scheduler is of more importance when it comes to reading data.
Schedulers designed for rotational media may prioritize the list queued
blocks with the rotation of the media in mind. For instance it probably
makes more sense to read consecutively as long as possible in case of
rotational media. SSDs on the other hand don't profit from consecutive
reads, and so it could make more sense to actually read the blocks just
like requested.

Keep in mind that these days with AHCI there is also NCQ, which allows
the controller of the HDD/SSD to rearrange requests for itself, so its
not just up to the scheduler, but also depends on the firmware of the
drive in question.

Furthermore, like basically every choice in regards to schedulers, it
very much depends on your workload. Personally I'm running with the
default values on various setups with SSDs and haven't noticed any
problems, especially because the kernel is smart enough to detect
whether or not the attached drive is "rotational" or not.

> In addition it is suggested that for a machine with a reasonable RAM (in my
> case 8GiB) then reducing the "swappiness" parameter to 1 via systemctl

With enough RAM (and 8 GiB are probably more than enough for most
workloads) it shouldn't make much of a difference at all, as your system
isn't swapping anything at all - at least mine isn't.

[root at vpcs ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          7853       5288       2564          0        281       2499
-/+ buffers/cache:       2508       5344
Swap:         8191          0       8191


> I have also seen it suggested that TRIM support is important

Well, it depends. TRIM (in theory) only increases the write speed
(respectively keeps it constant), because the cells will already be
erased when needed - just like when your drive is new. Without TRIM the
controller will have to erase the cells directly before writing to them,
which will obviously slow things down.

However you should keep in mind that in case you have some encrypted
containers this is some sort of information leakage, see [1]. Therefore
in this scenarios the default is to keep TRIM disabled.

Again, personally I haven't noticed much of an impact with my setups,
however I don't care when the write speed isn't as fast as advertised
and/or when the drive is new. I can live perfectly fine when it gets (a
little bit) slower over time.

> Finally I have seen suggested that the "noatime" flag be used for mounting
> SSD drives.

Yeah, that's pretty much the only "optimization" I've done here. To be
honest I think the "atime" option is quite stupid and I'm not alone with
this opinion, see [2].

> and has
> experience of SSD wear issues

I'm pretty sure that there is not a single person with "wear issues" on
this mailing list. This whole topic of "wearing" is pretty much
overrated. Current wear leveling technologies are pretty sophisticated
and most of the horrors scenarios you read about are made up.

A reputable magazine (called c't) here in Germany has tested a few SSDs
for their longevity (see [3]). They came to the conclusion that SSDs
reach the specified amount of written data easily, although they might
get slower after that they still work just fine. Furthermore there is
some sort of "self healing" involved with flash cells. Once you get some
read errors and leave the cell alone for itself long enough, chances are
good that due to various effects the data can finally be retrieved (see
[3]).

Far more critical are firmware bugs in the various controllers of recent
SSDs. There have been quite a few serious issues with complete data loss
as a result, so this should be your greatest concern - by far.

Furthermore you should have backups of important stuff anyway ...

> whether partitioning and installing essentially with
> defaults is going to lead to SSD problems

I haven't noticed any issues and beside the "noatime" mount option
haven't changed anything.

I don't know whether or not you've already read the Wiki article, see
[4]. I think its a good starting point for all of your questions and
most of it got covered there.

Best regards,
Karol Babioch

[1] http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html
[2] http://kerneltrap.org/node/14148
[3] https://www.heise.de/artikel-archiv/ct/2012/03/66
[4] https://wiki.archlinux.org/index.php/SSD

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130107/aaa58673/attachment.asc>