Three things come immediately to mind re. SSDs

1). Alignment of the partitions is critical for performance, Hopefully the tools you used during install did the right thing.
To check run "blockdev --getalignoff /dev/sdx[1-y]"
Where x is your drive (usually a for the first one) and y is the number of partitions.
If a '0' is returned, the partition is aligned

[root@alice ~]# blockdev --getalignoff /dev/sda[1-7]

0

0

0

0

0

0

0

[root@alice

2). Trim is more important when the disk is getting full and there is subsequently a much smaller pool of spare blocks for writes, So they then need to be turned around more quickly. If this house-keeping has to be done during the write, then the write is slowed down immensely. The SSD disks here are not very full so fstrim once a week is sufficient, run from any entry in crontab. In fact have a script so an email is sent...

#

# trim SSD crontab entry

03      06    *  * 7      /usr/local/bin/fstrim.sh   

#

Watch out for split lines in the script below... This website is the pits and its software consigned to the recycle bin ...

#!/bin/sh



# /usr/local/bin/fstrim.sh  

# Run fstrim on a SSD and format the reported bytes in human readable format

# Version 1.0 A G Ellis 22 June 2014



  /usr/sbin/fstrim -v / > /tmp/fstrim.message.txt

  MBytes_trimmed=`/usr/bin/cat /tmp/fstrim.message.txt | /usr/bin/awk '{print int($2/(1024*1024)) }'`

  MBytes_trimmed=`/usr/bin/printf "%'d" $MBytes_trimmed`

  Today=" on "`/usr/bin/date +%F`



  Email_body=$MBytes_trimmed" MBytes were trimmed "$Today" for disk /dev/sda installed in `/usr/bin/uname -n`"



  echo $Email_body | /usr/bin/mail -s "fstrim results for `/usr/bin/uname -n`" admin@sraellis.no-ip.com

  /usr/bin/rm /tmp/fstrim.message.txt

  exit

6,203 MBytes were trimmed on 2016-05-09 for disk /dev/sda installed in sophia

3). If you wish to cut down on the number of writes to curtail wear, search the web for hints on running Linux from flash or usb drives. One technique used here is the use of "noatime" for mounts. An example from an extract from /etc/fstab

... snipped

UUID=22c448e8-a9f6-4d09-be25-f5103809ca63 /               ext4  defaults,noatime        1 1

UUID=78e03fbb-5154-4254-ace4-3976f32d0e89 /boot           ext4  defaults,noatime        1 2

UUID=5bb6a384-d886-429c-8d7c-ecd875460ed8 /home           ext4  defaults,noatime        1 2

... snipped

Thanks Tony !

HeHe - this had me going for a minute or two...

Received an email from "root@server.lan" with the message (name of server obscured by consonants changed to x)

0 MBytes were trimmed on 2017-06-22 for disk /dev/sda installed in xaxexax.xuxex.xxxeax

Huh! - that's my wording of a particular script - what's going on? Has my system been hacked?
Then thought - maybe I posted that script here...
Voila! - whoever ran that script didn't change the email address the report was to be sent to

So whoever who are (probably in Mexico according to 'whois' using the original address in the email header) - please change the script so you get the email and not me...

Tony,
I was looking for some advice on how to trim an SSD I have in one of my ClearOS boxes and found this post. I copied your script (and did avoid putting your email address in). When I run the script manually to test it works I get this error:

fstrim: /: the discard operation is not supported

I looked this error up and some of the fixes looked a bit hairy for me so thought I would post here and see if you had a ClearOS specific angle on why I am getting this.
When I configured the server initially I used LVM so I am not sure if that has any bearing. My Server has the SSD which is a 500GB Western Digital drive, a 2TB Toshiba HDD and a 1TB Seagate HDD. It is running on the latest download of the community edition of ClearOS 7. The server is a Dell PowerEdge R540 rack server.

Siv

Siv - that was written back in 2014 on the days of ClearOS 6 - I suspect that the formatting of the output might be messed up with changes introduced in ClearOS 7. No longer run that script here as my SSDs are not very full so plenty of time for the SSD's internal housekeeping to maintian more than an adequate supply of free blocks. Nevertheless, just tried the command on my Version 7.6 (no LVM) - and the command still works...

[root@danda ~]# /usr/sbin/fstrim -v /

/: 7.8 GiB (8364064768 bytes) trimmed

root@danda ~]# cat /etc/*release* | grep "ClearOS release"

ClearOS release 7.6.0 (Final) 

I don't run LVM - so no real experience, (mine was back in the days of IBM OS2 Warp and 3.0). A quick google check revealed "We have to enable the option issue_discards in a LVM configuration" so suggest you do some research :-)

Tony,

Thanks for getting back. I don't know why but I am not getting notified that you had responded so apologies for only just replying.

I did have a look at the issue_discards and set that up, but I still get the same error. I suspect it's because the logical volume includes both SSD and HDDs so it's probably not able to trim everything.

Maybe won't use LVM in future.

I did put on the noatime option in /etc/fstab so I am hoping that's decreasing the writes.

Thanks again.


Siv