therapist

Thank you!

Seems pretty straightforward to make a BASH script to extract last LBA address and run sg_unmap When I run the command in 6.6.6 console I get command not found...is it something in Nerd Pack perhaps it came with?

Well there you go Next question is, can sg_unmap be used in place for TRIM on HBAs? does not look like unRAID has the sg_unmap command baked in

I was under the impression that HBAs in IT mode worked exactly like this, but somewhere along the line the mpt2SAS has reduced compatibility. There is a whole plugin dedicated to TRIM automation, I wonder how many users are out there & just don't realize it isn't working anymore. Not that it is the end of the world, but simply relying on internal GC for an SSD is not the best course.

I don't think this is necessarily the case as the LSI/Broadcom compatibility matrix lists (for sake of the topic) Samsung EVO drives as compatible with 9207 chipsets. As evidenced by my earlier tests, even an 840 PRO with DRAT is not working properly in later builds & I would imagine that there are plenty of users using earlier builds that had functioning TRIM with their EVO SSDs on HBAs. EDIT: https://docs.broadcom.com/docs-and-downloads/host-bus-adapters/IT_SAS_Gen_2.5CompatibilityList.pdf

I am in the process of consolidating hardware & would like to move a RAID0 array into a VM with UD. What I have been doing in the past to passthrough a disk is use disk-by-id in the KVM template and this works just fine, but is labeled as Red Hat VirtIO SCSI disk device by Windows 10. If I create a RAID0 array with UD, can the array be passed through by using the root device ID? If I pass through say 5 disks instead, will Win 10 Storage Spaces allow creating of an extended array with the QEMU emulated disks?

I don't think the 9211 cards were compatible with SSD TRIM at all....the 9207 was typically sought out as the card for SSD operation. It has more to do with LSI/Broadcom implementations than unraid. Just because @limetech has a "compatibility matrix" it doesn't mean that every combination of hardware is guaranteed to work. The end user has to do their due diligence. In my first post, I thought I was being pretty thorough...even buying additional hardware to try and make it work. Seems somewhere along the line the mpt2SAS driver has dropped TRIM support for the most commonly used drives? I am in the process of moving most of my drives to a direct attach backplane & will be experimenting more when done.

Basically, yes Ive had a love hate relationship with NEXTCLOUD & NginxPM finally got me to enjoy/actively use it

yes, I have it working perfectly

I have VMs on both br0 and br0.40 VLAN (default) and the script will not start w/ the variable $BRNAME or if br0.40 is hard coded. If I hard code br0, the service reports as started but I cannot seem to start any VMs via WoL Any advice? Also, how does one access VBMC? EDIT: I am running 6.6.6

Thank you! Ran into an issue with NginxProxyManager routing to dockers on br0 Was able to set up a docker VLAN and get everything sorted in like 10 minutes

6.6.6 back to normal with 2019.01.22a Thank you!

6.6.6 edit: array drives are displaying fine

experiencing same issue on edge/chrome w/ 2019.01.22 previous version had both usage columns skewed

Is this through a backplane or direct with HBA? I am extremely curious as to why the LSI devs would no longer support SAS2 TRIM funtionality

What if anything have you seen in the changelogs that would lead you to believe the TRIM issue on HBAs is corrected in 4.20? Seeing that 6.7 may only have 4.19 it looks like we're still off there

Does not appear that @limetech is updating the util-linux or mpt3sas packages in the 6.6.0 RCs mpt3sas now up to 27.100.00.00.

Thanks for keeping the light on with this I still cant figure why I was able to TRIM ext4 formatted disks

I find a few references to SSDs working with TRIM on UNRAID, but nothing recently which would coincide with LSI driver updates. I wonder how many people out there had this working & just don't realize they are no longer supported... In the mean time I've figured out that I can manually TRIM my HBA bound SSDs by stopping array, removing from chassis & hot plugging to mobo. Then mount with UD, fstrim & return to normally scheduled programming. The LSI driver is baked in to UNRAID, so is there any advice on where to bring up this issue with the keepers of that code?

Any ideas on why an ext4 formatted drive will still TRIM properly w/ current drivers?

I suppose youre right... @limetech is there any way that the end used can replace the LSI driver similar to: https://thevirtualist.org/replacing-driver-for-megaraid-sas-9361-8i-on-esxi-6/ It would be far easier to do this than keep buying more hardware to work around a software issue

Thank you for going through this! At least I know my hardware may not be at fault... Should this be submitted as a bug report?

diagnostics attached trim does work...my current cache ssd works fine on the X8DTI-F SATA connection and I was able to get the new 840 PRO to trim on the 9207-8e connected DAS, but only when the disk was ext4 formatted? ocho-diagnostics-20181004-1717.zip

So I purchased a Samsung 840 PRO SSD as it is the only drive I can confirm has DRAT Formatted BTRFS in UD -- mounted & tried FSTRIM -- got "remote I/O failed" error Formatted ext4 in UD -- mounted & trimmed -- BINGO! so maybe fstrim doesnt like BTRFS on HBAs....lets try xfs (this device is destined to be a cache disk after all) Formatted XFS in UD -- mounted & tried to TRIM -- "remote I/O failed" WTF? @limetech is there something with unraid that prevents HBA trim of BTRFS/XFS formatted devices? Any thought on allowing ext4 formatted cache disks? Any ideas @johnnie.black? It would be really nice to be able to utilize my higher bandwidth drives to their max, rather then gimp them with onboard 3Gb/s SATA

I know this is hard to extrapolate -- but what are the real world implications for no TRIM on a "consumer grade" SSD? The drive hosts VM images will garbage collection suffice?