JorgeB

That's one of the main use cases.

That might be more of an OSX issue, I don't' see that with Windows.

Checking the original diags to refresh my memory on what happened here I just noticed that disk8 failed to mount even before there were read errors during the rebuild: Feb 5 22:47:43 TC-NAS-01 emhttpd: shcmd (184): mount -t xfs -o noatime,nodiratime /dev/md8 /mnt/disk8 Feb 5 22:47:43 TC-NAS-01 kernel: XFS (md8): Mounting V5 Filesystem Feb 5 22:47:43 TC-NAS-01 kernel: XFS (md8): Log inconsistent (didn't find previous header) Feb 5 22:47:43 TC-NAS-01 kernel: XFS (md8): failed to find log head Feb 5 22:47:43 TC-NAS-01 kernel: XFS (md8): log mount/recovery failed: error -5 Feb 5 22:47:43 TC-NAS-01 kernel: XFS (md8): log mount failed Feb 5 22:47:43 TC-NAS-01 root: mount: /mnt/disk8: can't read superblock on /dev/md8. Feb 5 22:47:43 TC-NAS-01 emhttpd: shcmd (184): exit status: 32 Feb 5 22:47:43 TC-NAS-01 emhttpd: /mnt/disk8 mount error: No file system Feb 5 22:47:43 TC-NAS-01 emhttpd: shcmd (185): umount /mnt/disk8 Feb 5 22:47:43 TC-NAS-01 root: umount: /mnt/disk8: not mounted. This suggests there were already filesystem issues, so you can still continue but success depends on how bad that corruption was, but it might be easily fixable by xfs_repair, everything else looks fine for now, the procedure is: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed. -Important - After checking the assignments leave the browser on that page, the "Main" page. -Open an SSH session/use the console and type (don't copy/paste directly from the forum, as sometimes it can insert extra characters): mdcmd set invalidslot 8 29 -Back on the GUI and without refreshing the page, just start the array, do not check the "parity is already valid" box (GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the invalid slot command, but they won't be as long as the procedure was correctly done), disk8 will start rebuilding, disk should mount immediately (it likely won't mount in this case) but if it's unmountable don't format, wait for the rebuild to finish and then run a filesystem check

Lots of call traces, first ones seem to be xfs related, so start by running a filesystem check on all xfs filesystems: xfs_repair -v /dev/mdX Same for cache if xfs, also a good idea to run memtest.

30/50MB/s is about right for default writing mode, it should be faster with turbo write, at the expense of all drives spinning up for writes.

VMs usually pause when the device containing a vdisk runs out of space, you have one unassigned disk 100% allocated, is it used on that VM?

CRC errors are a connection problem, most times the SATA cable, but it can also be the controller, especially since you're using an old SIL controller and some of those are known to be unreliable, even corrupt data in some cases, start by replacing the SATA cable, and note that the attribute doesn't reset, so as long as it doesn't keep increasing the problem is solved.

It's fine to mount old cache with UD, but you can't use dd to clone it, since it won't expand the partition and Unraid would complain of invalid partition layout, you can format the new one with UD and copy everything from the old one with mc for example, don't copy the docker image, best to recreate it, and if copying vdisks best to use command line to keep them sparse. To format new drive you need to first remove existing partitions, click on + to expand then delete on the red x.

That's what I would recommend, but replace/swap cables before doing to rule them out in case it happens again.

Try this.

No, and extremely unlikely this has anything to do with upgrading Unraid. Parity can't help with filesystem corruption, it's also not a backup, it's for redundancy, you still need backups of any irreplaceable data. If you still have the old disk intact you can try to mount it with the UD plugin, it will need a new UUID if mounted with the array started, filesystem there might have less damage, or even no damage at all.

RC errors are a connection problem, most times the SATA cable, but it can also be the controller, backplane, etc, start by replacing the SATA cable, and note that the attribute doesn't reset, so as long as it doesn't keep increasing the problem is solved. The reallocated sectors are never good sign but since there are just a few and as long as they remain stable it should be OK, run an extended SMART test to confirm surface is good.

Not a good idea, when a disk fails Unraid needs to successfully read all the other drives to rebuild it (or all other but one with dual parity), though it also depends what you mean by questionable, any drive that fails the extended SMART test shouldn't be used, drives with a few reallocated sectors or other less serious SMART issues might be used, depending on your tolerance for failure.

Yes.

You can always make a feature request for LT to include that driver, they are usually good at including requested drivers, though since this one would be for a single user not sure, but it won't hurt to ask.

I believe not all GUI options work with SAS drives.

Never seen anyone using SCSI with Unraid, also don't forget it will likely only work with small drives, so IMHO not much point.

No driver is loaded: 03:04.0 SCSI storage controller [0100]: ATTO Technology, Inc. Ultra320 SCSI Host Adapter [117c:0030] (rev 08) Subsystem: ATTO Technology, Inc. ExpressPCI UL5D Low Profile [117c:802f] 03:04.1 SCSI storage controller [0100]: ATTO Technology, Inc. Ultra320 SCSI Host Adapter [117c:0030] (rev 08) Subsystem: ATTO Technology, Inc. ExpressPCI UL5D Low Profile [117c:802f] Not really a surprise: Unraid install strips all unneeded drivers/modules to keep it as small as possible.

I seem to remember a few other Ryzen users that got ECC errors @ 2400 and not @ 2666, problem might be that 2666 is overclocking for that configuration, and a server board might not let you do it, still it should never give errors at the supported frequency, bios up to date?

Diags are after rebooting, so we can't see what happened, but disk looks fine so likely a connection problem, if there weren't any writes to the array since you can re-enable parity to try the rebuilds again.

Please post the diagnostics: Tools -> Diagnostics

See if this helps: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

If it keeps crashing try safe mode for a couple of days (with dockers and VMs also stopped), if it still crashes like that it's likely a hardware problem.

Looks more like a a router problem, not leasing a DHCP address, but some user have a timing issue with current Unraid, see if running this helps: inet restart

You should post on the appropriate docker support thread. Sent from my iPhone, which I have. Case, charger, everything.