The number shown from the fstrim operation is the number of available bytes on the SSD.

 

I tested fstrim on my new 250GB Samsung SSD and got the following results:

 

Nov 23 08:45:45 Tower logger: /mnt/cache: 130988105728 bytes were trimmed

 

Can you comment on the difference in the available bytes reported by fstrim and those reported by the system. The WebGUI reports 41.4GB used and 209GB free.

 

root@Tower:~# df -k
Filesystem       1K-blocks    Used      Available  Use% Mounted on
/dev/sdh1        244198552    40393304  202931112  17%  /mnt/cache
root@Tower:~#

-v, --verbose

              Verbose execution.  With this option fstrim will output the

              number of bytes passed from the filesystem down the block

              stack to the device for potential discard.  This number is a

              maximum discard amount from the storage device's perspective,

              because FITRIM ioctl called repeated will keep sending the

              same sectors for discard repeatedly.

 

              fstrim will report the same potential discard bytes each time,

              but only sectors which had been written to between the

              discards would actually be discarded by the storage device.

              Further, the kernel block layer reserves the right to adjust

              the discard ranges to fit raid stripe geometry, non-trim

              capable devices in a LVM setup, etc.  These reductions would

              not be reflected in fstrim_range.len (the --length option).

http://man7.org/linux/man-pages/man8/fstrim.8.html

Tops. Easy installation and configuration.

 

As an intermediate step I have created a new plugin "SSD TRIM", which allows to set a schedule for the TRIM operation.

 

The set up can be found under Settings -> Scheduler -> SSD TRIM Settings

 

See Dynamix plugins for installation.

 

Thanks dlandon for all the research.

How about unassigned devices.  It's trying to trim my cache which is a reg hd.  I have 2 ssd for my docker and vms stuff

+1

How about unassigned devices.  It's trying to trim my cache which is a reg hd.  I have 2 ssd for my docker and vms stuff

+1

 

Drives formatted with xfs or ext4 will be mounted by UD with 'discard' which enables trim on SSD devices.

So you are saying that when I mount a SSD through UD it will automatically trim itself via the discard option?! Or do I have to kick discard off with a command?

So you are saying that when I mount a SSD through UD it will automatically trim itself via the discard option?! Or do I have to kick discard off with a command?

 

It's automatic.

Perfect, thank you.

Perfect, thank you.

 

Only xfs or ext4 formatted disks.

Mine is ext4 formated, so I am good :-)

Is this still needed in  6.2.2, or does Unraid handle SSD cache TRIM natively now? (I see no reference on SSD "trim" in the change-log up to 6.2.2)

Is this still needed in  6.2.2, or does Unraid handle SSD cache TRIM natively now? (I see no reference on SSD "trim" in the change-log up to 6.2.2)

 

Yes, still needed, there's a Dynamix plugin.

Hi guys, just looking for confirmation.

 

I'm running 1tb EVO 850 as my cache/docker/VM drive formatted with BTRFS

I'm running it off of my Dell H200 HBA on recent IT firmware (As this gives me SATA3 connectivity) 

I'm running Dynamix TRIM plugin.

 

I'm getting the following error via email notifications: 

fstrim: /mnt/cache: the discard operation is not supported

Is this because i'm running BTRFS or because it's connected via HBA on IT Firmware?

 

Lastly, should i be running on a daily or weekly schedule?

Is it a big deal if i can't issue the FSTRIM command to my SSD?

 

Hi guys, just looking for confirmation.
 
I'm running 1tb EVO 850 as my cache/docker/VM drive formatted with BTRFS
I'm running it off of my Dell H200 HBA on recent IT firmware (As this gives me SATA3 connectivity) 
I'm running Dynamix TRIM plugin.
 
I'm getting the following error via email notifications: 

fstrim: /mnt/cache: the discard operation is not supported

Is this because i'm running BTRFS or because it's connected via HBA on IT Firmware?
 
Lastly, should i be running on a daily or weekly schedule?
Is it a big deal if i can't issue the FSTRIM command to my SSD?
 

SAS2008 based controllers don't support trim on most SSDs, you should connect the SSD on the onboard controller, swap with another disk if needed.

Right - Thanks for the confirmation -  What are the consequences of powering down -> swapping over the SSD to mainboard SATA0 port -> turning on  

 

Will i need to play around with anything prior?

Right - Thanks for the confirmation -  What are the consequences of powering down -> swapping over the SSD to mainboard SATA0 port -> turning on [emoji4] 
 
Will i need to play around with anything prior?

No.

Great stuff. It's just a matter of reassigning the new slot to the cache drive when it comes back up?

13 minutes ago, thestraycat said:

Great stuff. It's just a matter of reassigning the new slot to the cache drive when it comes back up?

 

Devices are tracked by serial number, not controller port, you wont need to do anything.

Thanks Johnnie

I had the same issue with "the discard operation is not supported".  I checked my Samsung 128gb ssd and it was plugged into an pci-e board (https://www.amazon.com/gp/product/B005B0A6ZS/ref=oh_aui_search_detailpage?ie=UTF8&psc=1) .  I switched the cable to the on-board sata and i'm still getting the same error.  Any advice?

 

Running 6.3.2 

I recently had an external HDD attached and mounted with the path '/mnt/disks/External_Data_1'.

 

Ever since I unmounted and removed said external HDD I get this annoying email everytime the trim runs:
 

Header of the email: "cron for user root /sbin/fstrim -a -v | logger &> /dev/null"

Content of the email: "fstrim: /mnt/disks/External_Data_1: FITRIM ioctl failed: No such file or directory"

 

I have tried deleting and reinstalling the plugin, but this did not solve the issue.

I solved it myself: I removed the drive from "historical devices" on the main pane in unraid. Then I rebooted the whole server and tested. The issue is no more.

Edited October 5, 20178 yr by JohanSF

Finally swapped out my cache drive with a Samsung 1tb 860.  Trim was working however i started to have issues with the drive.  It would grind to a halt once it got to 180 GB on it.  I decided to exchange it for a Crucial MX500 1TB.  it seems to be doing much better however when i run the trim command i get fstrim: /mnt/cache: the discard operation is not supported.  Any ideals what's going on?

1 minute ago, dertbv said:

Any ideals what's going on?

Likely it's on a controller that doesn't support trim, use the onboard SATA ports for the SSD

It is using the same controller the samsung drive was using when it was working..

 

I assume that these two directories are on the cache drive?

sudo fstrim -a -v
/var/lib/docker: 11.9 GiB (12789510144 bytes) trimmed
/etc/libvirt: 921.6 MiB (966324224 bytes) trimmed
 

Edited December 31, 20187 yr by dertbv

Just now, dertbv said:

It is using the same controller the samsung drive was using when it was working..

That doesn't mean anything, Samsung supports read zero after trim, Crucial doesn't, so for example the Samsung would work on some LSI controllers, the Crucial won't, but it will work on the onboard SATA ports.