JorgeB

I did try it, and IIRC it worked even on SAS2 HBAs, but I didn't see a way to use it like fstrim. i.e., you need to specify which blocks you're unmapping, I used it on the whole device, and it resulted in all sectors wiped, same as if using blkdiscard.

Also check this: https://www.broadcom.com/support/knowledgebase/1211161496937/trim-and-sgunmap-support-for-lsi-hbas-and-raid-controllers

I tested with the old driver included with v6.3.5 and no LSI HBA trims a non RZAT SSD, I tested with the 9211-8i, 9207-8i and 9300-8i.

No, LSI trim only works for HBAs in IT mode, no RAID, but still requires determinist read after TRIM, don't know why.

I've been using it for years now on all my Unraid servers, though won't dispute that is not as stable as xfs, but for anyone with backups (and you should always have backups), a stable server and an UPS, there's no reason not to use it.

Looks like btrfs can also be used for shadow copies with Samba, but never tried it: https://forum.openmediavault.org/index.php/Thread/7331-GUIDE-Windows-Previous-Versions-and-Samba-Btrfs-Atomic-COW-Volume-Shadow-Copy/

Check is starting at the expected speeds for your disks, around 170MB/s, it's normal to then gradually slow down, but the averages should be around 130MB/s like previous ones. Maybe you're using the array during the check? If not try to check the speed every few minutes and see if speeds go up and down.

One more thing, since this thread is also about Samsung SSDs, all Samsung consumer SSD models prior to the 860 EVO don't support deterministic reads after TRIM, so if for example you have an 850 EVO it will never be trimmed by an LSI HBA. I believe the PRO models are different, and most support it, you can easily check with hdparm: OK for LSI HBA: hdparm -I /dev/sdc | grep TRIM * Data Set Management TRIM supported (limit 8 blocks) * Deterministic read ZEROs after TRIM Not OK for LSI HBA: hdparm -I /dev/sdb | grep TRIM * Data Set Management TRIM supported (limit 8 blocks)

Up to Unraid 6.3.5, mpt3sas driver 13.100.00.00, TRIM works on LSI SAS2 and SAS3 HBAs, starting with Unraid 6.4.1, mpt3sas driver 15.100.00.00, TRIM stopped working on SAS2 HBAs, like the 9211-8i, 9207-8i, etc, but still works on SAS3 HBAs like the 9300-8i. But note that for all cases, TRIM with LSI HBAs only works on SSDs with deterministic read zeros after TRIM, for SSDs with no deterministic read after TRIM you get the standard TRIM unsupported error when running fstrim: the discard operation is not supported When running fstrim with a SAS2 LSI HBA on an SSD with deterministic read trim support and latest drivers you get a different more cryptic error: FITRIM ioctl failed: Remote I/O error

It's not an Unraid problem, it's the Linux LSI driver, current status is the same as my post above on January 17th.

It still doesn't work, it does on SAS3 HBAs based on the SAS3008 chipset, only on SSDs with deterministic read after TRIM.

I don't use encryption but was able to reproduce this issue, load average goes sky high and writes to the array with encryption enable, xfs or btrfs, are very slow, though encrypted cache seems unaffected, or at least much less so.

There appears to be some issues with encryption and slow writes with v6.7

https://forums.unraid.net/topic/57181-real-docker-faq/?do=findComment&comment=564309

Feb 10 16:21:58 NAS kernel: BTRFS warning (device loop2): csum failed root 5 ino 15295 off 0 csum 0x98f94189 expected csum 0xd349d779 mirror 1 Docker image is corrupt, delete and recreate.

Cache pool is showing checksum errors on both devices, this is most often caused by bad RAM, suggest running memtest. Feb 9 16:44:48 UnRaid kernel: BTRFS info (device sdj1): bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 Feb 9 16:44:48 UnRaid kernel: BTRFS info (device sdj1): bdev /dev/sdi1 errs: wr 0, rd 0, flush 0, corrupt 26, gen 0 The bad key order error is metadata corruption, possibly also from a flipped bit, to solve this (ideally after fixing what caused this in the first place) better to backup cache, reformat and restore.

Not always, depends on the board's number of DIMM slots and PCB layers:

With Ryzen you should keep to the max non overclocked RAM speeds depending on your config, or risk instability and sync errors:

Happy for you, still unrelated. Let me refrase that, almost certainly unrelated and it wouldn't make any sense, but stranger things have happened.

Yes, drive that fails SMART test = failed drive Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 26 - # 2 Short offline Completed: read failure 10% 26

Old SAS1 models support up to 2TB, all SAS2 (SAS2xxx) and SAS3 (SAS3xxx) models support any size.

Strange then, no more ideas.

Maybe AES is disable in the bios.

Yes, Ironwolf is the same?

Your CPU should handle encryption just fine, only CPUs without AES could have some trouble.