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