I've been reading some conflicting posts that say the dynamix trim plugin is required and others saying that unraid natively supports trim now. Should I be running the dynamix plugin for my SSD cache or is unraid taking care of it? If unraid has support for it natively is there anything I need to do to enable trim support or is it done automatically?

2 hours ago, Ericjr said:

f unraid has support for it natively is there anything I need to do to enable trim support or is it done automatically?

With v6.8 you need to run trim manually, with v6.9 no need to trim any btrfs pool since it uses the new discard=async mount option, still need to do it for any xfs filesystem.

Thank you.  

I removed the Trim plugin (on RC2) but now Fix Common problems is warning me that it's not installed - should I ignore it?

56 minutes ago, CS01-HS said:

should I ignore it?

If your pools are all btrfs you can ignore.

What i have to do, for using "discard=async"?

11 hours ago, sonic6 said:

What i have to do, for using "discard=async"?

Nothing other than upgrading to v6.9.x.

I have a backup server that doesn't have any cache at all.  However, Fix Common Problems keeps telling me that I need to download SSD Trim?  Any clues???

Thanks in advance

11 minutes ago, isrdude said:

Fix Common Problems

You should post in the existing plugin support thread:

 

I'm not convinced that trim is working the way it should be.  I have two nvme devices each in their own named btrfs cache pool, and performance over time on these devices plummets down until i'm seeing less than 20MB/s write speeds when copying files.  If i manually force a trim, i then see (as an example) 85GB trimmed, and the drive then speeds back up again.  The system log is showing the drive as having been trimmed with the dynamix plugin, but it just doesn't look like it's working to me.  Perhaps i need to completely remove the dynamix plugin if its not needed? On unRAID 6.9.2 by the way

Edited July 16, 20214 yr by sdamaged

12 minutes ago, sdamaged said:

If i manually force a trim, i then see (as an example) 85GB trimmed, and the drive then speeds back up again.

if there are no errors manual trim is the same as the Dynamix trim.

On 3/19/2021 at 9:30 PM, sonic6 said:

What i have to do, for using "discard=async"?

 

On 3/20/2021 at 8:42 AM, JorgeB said:

Nothing other than upgrading to v6.9.x.

 

Where can i verify this on the system? Can't find the option for this. Btw, using 6.10 now. Is the dynamics trim plugin just not needed, or can it cause problems if it installed on the newer Unraid versions? Maybe because of the own trim operation is colliding with the ones from the plugin? 

19 hours ago, TecEgg said:

Can't find the option for this.

There's no option to change, it's a mount option.

 

19 hours ago, TecEgg said:

or can it cause problems if it installed on the newer Unraid versions?

It won't cause any issues also using the plugin.

On 1/23/2021 at 9:40 AM, JorgeB said:

With v6.8 you need to run trim manually, with v6.9 no need to trim any btrfs pool since it uses the new discard=async mount option, still need to do it for any xfs filesystem.

Does that also apply to btrfs encrypted? I read somewhere that trim is not supported with encryption.

10 minutes ago, JonasH said:

Does that also apply to btrfs encrypted?

Don't know, never used encryption.

On 3/20/2021 at 3:42 AM, JorgeB said:

Nothing other than upgrading to v6.9.x.

Maybe a stupid question, but does this hold if your drive does not support TRIM? I have a couple SSD's mounted to an HBA and I get a "not supported" message when I run the fstrim -v command. 

1 hour ago, NormanB said:

but does this hold if your drive does not support TRIM?

It won't work the same.

On 1/23/2021 at 8:40 AM, JorgeB said:

With v6.8 you need to run trim manually, with v6.9 no need to trim any btrfs pool since it uses the new discard=async mount option, still need to do it for any xfs filesystem.

 

Is there any harm in keeping the trim function even when the cache is a btrfs pool? Or should I just remove trim and be done with it? I just don't want to be getting warnings about not having it from Fix Common Problems (I know this isn't the Fix Common Problems thread).

16 minutes ago, takkischitt said:

Is there any harm in keeping the trim function even when the cache is a btrfs pool?

Nope.

fstrim -v /mnt/cache
/mnt/cache: 444 GiB (476746616832 bytes) trimmed

 

that's on a 500GB SSD with 6.9.2 running.  we've had performance issues on the system recently, and when I copied the VMs off the drive, it was barely moving data.  then I ran the command above.

something tells me it's not TRIMming the drive like its supposed to.

It will only trim the free space.

yea. that was the free space.  the problem is the disk only was using 77GB until recently, when I moved the VMs off of it.  it clearly hasn't been TRIMming on a regular basis.

Using unraid 6.11.5

Single nvme drive in cache, btrfs. No scrub/anything special.

 

We were talking in discord recently about this, and I notice that my cache (created 6.9.x after the 1 MiB alignment) doesnt include the discard option like it mentions it should:

 

# mount | grep /mnt/cache
/dev/nvme0n1p1 on /mnt/cache type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/mnt/cache/docker.img on /var/lib/docker type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/mnt/cache/docker.img on /var/lib/docker/btrfs type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/mnt/cache/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw,noatime,ssd,space_cache=v2,subvolid=5,subvol=/)

 

Is there a known bug/issue where it doesnt add the discard option if its a pool named 'cache' or only single drive with some other criteria?

Edited February 17, 20233 yr by zoggy

26 minutes ago, zoggy said:

Single nvme drive in cache

Currently only pools have the discard option enabled, but you can have a single device pool by setting pool slots to >1.