Re: Optimising ssd setup?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxx


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux