[arch-general] Optimising ssd setup?
As part of my planning for setting up a home build computer which will use two ssd drives - one a Crucial M4 mSATA drive (for root and boot partitions) and a second larger Crucial M4 SATA III drive for the rest, I have been reading up about partitioning and optimising such drives - It seems that it is important to partition with proper alignment to MiB boundaries for partitions but I am unclear if this happens automatically or not when setting up GPT partitions with gparted? ( I usually partition using a liveusb running PartedMagic and then run gparted before installing arch) Also I have been seeing various bits of advice about ensuring that excessive writes are avoided by using a non-default IO scheduler - with "deadline" being the better option for SSDs than the default CFQ scheduler - and it would seem that adding the parameter to the kernel line for boot once a system is set up is perhaps a good way forward? How does that work if UEFI booting? 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, or altering the relevant parameter under /proc/sys is the way to do it, even if there is a swap partition on one of the SSDs. I have also seen it suggested that TRIM support is important either mounting with the "discard" option or running fstrim manually via a cron job out of hours to avoid delays during writes whilst the system is in use. Finally I have seen suggested that the "noatime" flag be used for mounting SSD drives. Can anyone on this list who has set up a recent SSD drive and has experience of SSD wear issues, and levelling issues, offer any advice on whether some or all of the above are important when using SSD drives in an arch linux machine or whether partitioning and installing essentially with defaults is going to lead to SSD problems, or not? This will be my first foray into using SSD drives on any of my systems. Thanks for any replies. -- mike c
On 01/07/13 at 04:24pm, Mike Cloaked wrote:
As part of my planning for setting up a home build computer which will use two ssd drives - one a Crucial M4 mSATA drive (for root and boot partitions) and a second larger Crucial M4 SATA III drive for the rest, I have been reading up about partitioning and optimising such drives -
It seems that it is important to partition with proper alignment to MiB boundaries for partitions but I am unclear if this happens automatically or not when setting up GPT partitions with gparted? ( I usually partition using a liveusb running PartedMagic and then run gparted before installing arch)
I am not user about gparted, but I know that gptfdisk handles this automatically as does fdisk these days. I am not so familiar with parted in general, so maybe someone else can step in here.
Also I have been seeing various bits of advice about ensuring that excessive writes are avoided by using a non-default IO scheduler - with "deadline" being the better option for SSDs than the default CFQ scheduler - and it would seem that adding the parameter to the kernel line for boot once a system is set up is perhaps a good way forward? How does that work if UEFI booting?
I use a udev rule to determine what scheduler should be used for what. At one point I had both rotational disks and a solid state drive. So I continued to use CFQ for the rotational and I use NOOP for the flash based media. This is what I use: ACTION=="add", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", \ ATTR{queue/scheduler}="noop"
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, or altering the relevant parameter under /proc/sys is the way to do it, even if there is a swap partition on one of the SSDs.
If you have 8GB of RAM, you probably don't need swap. I have 8GB and don't use it. I have seen no ill effects, no OOM. But yes, if you have it, lower your swappiness and it will avoid writing to disk as much as it can.
I have also seen it suggested that TRIM support is important either mounting with the "discard" option or running fstrim manually via a cron job out of hours to avoid delays during writes whilst the system is in use.
Finally I have seen suggested that the "noatime" flag be used for mounting SSD drives.
I use noatime in general, as I don't really care about access times. It will still record times when you make changes to a file, so that is enough for me. Apparently, using noatime with mutt can mess mutt's functionality up. But this negative consequence can be minimized by using a Maildir if you use mutt. I personally use an anacron job to apply fstrim to my drives once a day. I find that is more than than enough. There are some drives that apparently are slowed down quite a bit when set to do trim on real time. I don't think that my drives are in this category, but I like being able to set the nice value of fstrim, so that is why I do it that way.
Can anyone on this list who has set up a recent SSD drive and has experience of SSD wear issues, and levelling issues, offer any advice on whether some or all of the above are important when using SSD drives in an arch linux machine or whether partitioning and installing essentially with defaults is going to lead to SSD problems, or not?
I don't think you need to worry about wearing out the drive. As long as you have a quality drive, which the Crucial M4s are, you should have no problems.
This will be my first foray into using SSD drives on any of my systems.
Thanks for any replies.
-- mike c
-- Sugar & Scruffy sugar.and.scruffy@gmail.com
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@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
On Mon, Jan 7, 2013 at 5:52 PM, Karol Babioch
Hi,
Am 07.01.2013 17:24, schrieb Mike Cloaked:
but I am unclear if this happens automatically or 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
Yes I have read the arch wiki articles which are very helpful as you say - though I wanted to also hear of real experiences which you and Karol have both replied about and which are very re-assuring - and it seems that modern quality SSD drives are much less likely to have problems than those that were available only a few years ago - I have my ssd drives ready to install onto the motherboard. Now I am quite looking forward to putting the hardware together and getting the install done - and seeing how it all works with the OS running with the best practice set up according to the advice and help I have had from the replies from this list. So thank you for your help and hints and tips - it is very much appreciated. -- mike c
On Mon, Jan 7, 2013 at 11:12 AM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
On 01/07/13 at 04:24pm, Mike Cloaked wrote:
As part of my planning for setting up a home build computer which will use two ssd drives - one a Crucial M4 mSATA drive (for root and boot partitions) and a second larger Crucial M4 SATA III drive for the rest, I have been reading up about partitioning and optimising such drives -
It seems that it is important to partition with proper alignment to MiB boundaries for partitions but I am unclear if this happens automatically or not when setting up GPT partitions with gparted? ( I usually partition using a liveusb running PartedMagic and then run gparted before installing arch)
I am not user about gparted, but I know that gptfdisk handles this automatically as does fdisk these days. I am not so familiar with parted in general, so maybe someone else can step in here.
Also I have been seeing various bits of advice about ensuring that excessive writes are avoided by using a non-default IO scheduler - with "deadline" being the better option for SSDs than the default CFQ scheduler - and it would seem that adding the parameter to the kernel line for boot once a system is set up is perhaps a good way forward? How does that work if UEFI booting?
I use a udev rule to determine what scheduler should be used for what. At one point I had both rotational disks and a solid state drive. So I continued to use CFQ for the rotational and I use NOOP for the flash based media. This is what I use:
ACTION=="add", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", \ ATTR{queue/scheduler}="noop"
Yet, according to https://bugs.archlinux.org/task/22605, CFQ should be able to handle SSD just fine. So does it really make a big difference? Sander
Hi, Am 07.01.2013 19:32, schrieb Sander Jansen:
So does it really make a big difference?
No, it doesn't. Take a look at [1] for instance and see for yourself. As already said the kernel (including the IO scheduler) by now is absolutely capable of detecting whether or not the attached device(s) are "rotational" or not and act appropriately. In general there is not much you have to do, although there might be workloads where the defaults are not good enough. However this is also true for classical rotational media. [1] http://www.velobit.com/storage-performance-blog/bid/126135/Effects-Of-Linux-... Best regards, Karol Babioch
participants (4)
-
Curtis Shimamoto
-
Karol Babioch
-
Mike Cloaked
-
Sander Jansen