So it seems the XFS filesystem stores the UUID in the superblock. Since unraid’s new disk rebuild is the same as the old, I guess it will show the same UUID.
 

If this is correct apparently you can generate a new UUID with:

 

xfs_admin -U generate /dev/sdx1

 

were x is the drive’s designated letter.

 

otherwise the system will not let me mount the drive.

 

 

 

 

 

Hello.

I have a three SSDs in my server.  Two are set up as a mirrored cache using btrfs.  The third is my Steam Library and is not part of the array or cache, but just in Unassigned Devices.

When I attempt to run fstrim -a -v it trims libvirt, docker, and /mnt/cache.

 

However it errors out on the 1TB SSD in UD with this error: "fstrim: /mnt/disk/1TB-SSD-Games: FITRIM ioctl failed: Remote I/O error"

The only difference between the cache and the unassigned SSD is that the cache is btrfs and the other is xfs.

 

When I run the hdparm -I command against the disk it shows that it supports the following:

- Data Set Management TRIM Supported (limit 8 blocks)

- Deterministic read ZEROs after TRIM

This suggests that it supports TRIM and should work as my cache drives report the same.

What's the meaning of this error, and should I be concerned?

 

Thanks in advance!

Edited December 4, 20196 yr by aidenpryde

32 minutes ago, aidenpryde said:

Hello.

I have a three SSDs in my server.  Two are set up as a mirrored cache using btrfs.  The third is my Steam Library and is not part of the array or cache, but just in Unassigned Devices.

When I attempt to run fstrim -a -v it trims libvirt, docker, and /mnt/cache.

 

However it errors out on the 1TB SSD in UD with this error: "fstrim: /mnt/disk/1TB-SSD-Games: FITRIM ioctl failed: Remote I/O error"

The only difference between the cache and the unassigned SSD is that the cache is btrfs and the other is xfs.

 

When I run the hdparm -I command against the disk it shows that it supports the following:

- Data Set Management TRIM Supported (limit 8 blocks)

- Deterministic read ZEROs after TRIM

This suggests that it supports TRIM and should work as my cache drives report the same.

What's the meaning of this error, and should I be concerned?

 

Thanks in advance!

Fixed in next release of UD.

1 hour ago, dlandon said:

Fixed in next release of UD.

Ah, any ETA on that?

 

Thanks!  I was worried I'd have to migrate things from my SSD to my gaming system directly.

The 12/6/19 update did not resolve the issue, is that the next release you were referring to?

1 hour ago, aidenpryde said:

The 12/6/19 update did not resolve the issue, is that the next release you were referring to?

Post diagnostics.

6 hours ago, dlandon said:

Post diagnostics.

What would you like me to post?  The output of fstrim -a -v in terminal?  It's doing the same thing I originally reported.

9 minutes ago, aidenpryde said:

What would you like me to post?  The output of fstrim -a -v in terminal?  It's doing the same thing I originally reported.

Diagnostics is a zip file created at Tools->Diagnostics.  Whenever you ask for help, post this diagnostic file.  It contains information that can be used to help you determine the issues.

 

I tested this on a UD mounted disk and it worked fine.  I think your SSD is on a controller that does not support trim.

5 hours ago, dlandon said:

Diagnostics is a zip file created at Tools->Diagnostics.  Whenever you ask for help, post this diagnostic file.  It contains information that can be used to help you determine the issues.

 

I tested this on a UD mounted disk and it worked fine.  I think your SSD is on a controller that does not support trim.

That doesn't make sense as my two other SSDs are on the same LSI 9211-8i.

 

The output of terminal:

/etc/libvirt: 920.5 MiB (965246976 bytes) trimmed on /dev/loop3
/var/lib/docker: 13.2 GiB (14156746752 bytes) trimmed on /dev/loop2
fstrim: /mnt/disks/1TB-SSD-Games: FITRIM ioctl failed: Remote I/O error
/mnt/cache: 409 GiB (439094415360 bytes) trimmed on /dev/sdb1

 

But here's the diagnostics:

diagnostics-20191207-0952.zip

 

Thanks for the help.

12 minutes ago, aidenpryde said:

That doesn't make sense as my two other SSDs are on the same LSI 9211-8i.

There's a known issue with LSI SAS2 models and trim with latest firmwares (>p16), the only strange thing here is that trim it is working on the cache devices, more so since it should never work on the 850 EVO as LSI requires deterministic read zeros after trim for trim to work, 860 EVO would be OK, maybe the mixed pool is confusing it?

 

 

28 minutes ago, johnnie.black said:

There's a known issue with LSI SAS2 models and trim with latest firmwares (>p16), the only strange thing here is that trim it is working on the cache devices, more so since it should never work on the 850 EVO as LSI requires deterministic read zeros after trim for trim to work, 860 EVO would be OK, maybe the mixed pool is confusing it?

 

 

I'd read mixed reports on that, and assumed since it was working on cache that the issue had since been resolved.  I need to get another HBA anyway because I need more drives.  Can I mix different model HBA's with Unraid?  If so, what used models can I get that will support TRIM so I can plug the SSDs into it?

2 minutes ago, aidenpryde said:

Can I mix different model HBA's with Unraid?

Yes, you can also use the onboard SATA ports for any SSD, LSI SAS3 models, like the 9300-8i support trim, but only on the devices with determinist trim, you can check with:

 

OK for LSI

hdparm -I /dev/sdc | grep TRIM

	* Data Set Management TRIM supported (limit 8 blocks)
	* Deterministic read ZEROs after TRIM

Not OK for LSI
 

hdparm -I /dev/sdb | grep TRIM

	* Data Set Management TRIM supported (limit 8 blocks)

 

 

1 hour ago, johnnie.black said:

Yes, you can also use the onboard SATA ports for any SSD, LSI SAS3 models, like the 9300-8i support trim, but only on the devices with determinist trim, you can check with:

 

OK for LSI

hdparm -I /dev/sdc | grep TRIM

	* Data Set Management TRIM supported (limit 8 blocks)
	* Deterministic read ZEROs after TRIM

Not OK for LSI
 

hdparm -I /dev/sdb | grep TRIM

	* Data Set Management TRIM supported (limit 8 blocks)

 

 

Ah.  Okay, so the Samsung 850 SSD won't work on the controller.  But I could hook it up to the onboard SATA and it would TRIM?  It's part of the cache pool and I'm not sure if that would be a good idea to have one part of the cache using a different controller?

Just now, aidenpryde said:

But I could hook it up to the onboard SATA and it would TRIM?

Yes.

 

1 minute ago, aidenpryde said:

It's part of the cache pool and I'm not sure if that would be a good idea to have one part of the cache using a different controller?

Would be fine, but you could also use the onboard ports for all SSDs.

1 minute ago, johnnie.black said:

Yes.

 

Would be fine, but you could also use the onboard ports for all SSDs.

I have a newer 500GB Crucial SSD that should support both of those functions (I don't trust this board's onboard SATA as when I was using it as a workstation if I hooked more than 2 SSDs up to it the computer would bluescreen, it's an ASUS Rampage IV Extreme which should have supported it). 

 

I think I'll remove the 850 Evo from the equation and use it later to expand my Steam Library as it's so old, I was just using it until it died and I don't care if I lose a Steam library.

 

So it sounds like I need to get a newer SAS HBA for the SSD's.  What are the LSI chips called that you mentioned?  Are they like the LSI SAS 3008 mentioned here: https://www.servethehome.com/flash-lsi-sas-3008-hba-e-g-ibm-m1215-mode/

1 minute ago, aidenpryde said:

Are they like the LSI SAS 3008

Yep, that's the one used by the 9300-8i and similar HBAs.

 

The Intel ports on the Asus should be rock solid, unless the board has a problem, even the Asmedia ports usually work without any issues, Marvell controllers on the other hand you should stay away from.

3 minutes ago, johnnie.black said:

Yep, that's the one used by the 9300-8i and similar HBAs.

 

The Intel ports on the Asus should be rock solid, unless the board has a problem, even the Asmedia ports usually work without any issues, Marvell controllers on the other hand you should stay away from.

Hmm, looks like I was plugging things into the ASMedia ports and not the Intel ports.  The reason I was doing that is that they are SATA2 ports which would hobble the SSDs.  I plan on replacing this in the next year and I'd planned to get another HBA anyway so I think I'll stick with that.  Off to Ebay I go.

8 minutes ago, aidenpryde said:

The reason I was doing that is that they are SATA2 ports which would hobble the SSDs.

2 of the Intel ports are SATA3

7 minutes ago, johnnie.black said:

2 of the Intel ports are SATA3

Right you are.  I guess I could give those a try.

1 hour ago, johnnie.black said:

2 of the Intel ports are SATA3

So, I moved things to the onboard SATA and it took longer to TRIM which I think means it did more than it was doing before, but it didn't even try to TRIM the non-Cache drive.  How do I trim a disk from terminal that's not part of the array?

I'm getting the following error with one of my disks. I had to reboot unraid, so it's been awhile since the mount script has run, but this is happening now. I'm on the latest version of the script (2019.12.06). 

Dec 7 07:49:21 mediatower unassigned.devices: Adding disk '/dev/sdi1'...
Dec 7 07:49:21 mediatower unassigned.devices: Mount drive command: /sbin/mount -t reiserfs -o auto,async,noatime,nodiratime,discard '/dev/sdi1' '/mnt/disks/scratch1'
Dec 7 07:49:21 mediatower kernel: REISERFS warning (device sdi1): super-6502 reiserfs_getopt: unknown mount option "discard"
Dec 7 07:49:21 mediatower unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/scratch1: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error.

 

I logged in to my server and ran the command without the discard option and it worked fine. Thoughts?

45 minutes ago, jtenman said:

I'm getting the following error with one of my disks. I had to reboot unraid, so it's been awhile since the mount script has run, but this is happening now. I'm on the latest version of the script (2019.12.06). 

Dec 7 07:49:21 mediatower unassigned.devices: Adding disk '/dev/sdi1'...
Dec 7 07:49:21 mediatower unassigned.devices: Mount drive command: /sbin/mount -t reiserfs -o auto,async,noatime,nodiratime,discard '/dev/sdi1' '/mnt/disks/scratch1'
Dec 7 07:49:21 mediatower kernel: REISERFS warning (device sdi1): super-6502 reiserfs_getopt: unknown mount option "discard"
Dec 7 07:49:21 mediatower unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/scratch1: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error.

 

I logged in to my server and ran the command without the discard option and it worked fine. Thoughts?

Is the disk an ssd?

14 minutes ago, dlandon said:

Is the disk an ssd?

Yes, it's an ssd.

18 minutes ago, dlandon said:

Is the disk an ssd?

Quote

Starting from reiser4-for-3.16.2 SSD users can mount their reiser4 partitions with the option "discard" and the file system will issue discard requests to inform the device that blocks are not longer used.

 

Doesn't look like reiser3 supports discard.

14 minutes ago, Squid said:

 

Doesn't look like reiser3 supports discard.

Is this a bug or is there something I can do to fix it? I haven't done anything custom on this, so not sure what the fix is to the problem.