JorgeB

Any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed. There are also models with more ports if 8 are not enough (-16i/-24i) or you can add a SAS expander at any time.

It should, but note that the mover won't move any exiting or open files.

I would return it, those controllers use SATA port multipliers and have multiple known issues with Unraid.

No, it would move it to the array: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=537383

Yes if all other disks are working correctly, but I would would prefer to check the diags first.

It's up to you, very difficult to predict if it will last, also depends on your risk tolerance, if you have backups or not, single/dual parity etc, I would have no problem using it, but I have full backups and dual parity on most of my servers.

It is being emulated, that's why you can still see and access its data. Diags are after rebooting so we can't see what happened, but the disk looks healthy, possibly a connection issue, also there are some known controller issues with the Ryzen SATA controller and older kernels. If the data on the emulated disk looks correct you can re-enable the disk, you can replace/swap cables before doing it to rule them out, and if any more issues grab the diags before rebooting.

Try recreating the flash drive: backup current one, re-doit using the USB tool, restore config folder from backup.

Good catch! I've seen weird issues before with those controllers AMD set to IDE before, like not being able to format or even assign a device, but first time I see this!

It is always possible to have "bad" parity when there are hardware issues, as long as now you can run two (or more) consecutive parity checks without errors you should be fine, also make sure there are no more controller related errors, that's no an Unraid problem, it's a Ryzen problem (likely with older kernels only).

-run a single stream ipert test to confirm network is working correctly -post diags grabbed during a slow tranfer

Diags are not opening for me, but This won't do anything for any data already on cache, you need to change the shares to use cache="yes" and run the mover.

Please post the diagnostics: Tools -> Diagnostics

They are the result of something connecting with the NFS protocol. Never used NFS but it's not usually that chatty. A reboot will clear it but you might want to try and decrease all that chatting.

Cache device dropped offline, check cables then post a SMART report (or new diags)

These are what is spamming your log: Mar 30 15:59:14 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.128:519 for /mnt/user/Media (/mnt/user/Media) Mar 30 15:59:14 Mediaserver rpcbind[18335]: connect from 192.168.0.128 to null() Mar 30 15:59:14 Mediaserver rpcbind[18336]: connect from 192.168.0.128 to getport/addr(nfs) Mar 30 16:02:13 Mediaserver rpcbind[23302]: connect from 192.168.0.128 to null() Mar 30 16:02:13 Mediaserver rpcbind[23303]: connect from 192.168.0.128 to getport/addr(mountd) Mar 30 16:02:13 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.128:525 for /mnt/user/Pictures (/mnt/user/Pictures) Mar 30 16:02:13 Mediaserver rpcbind[23313]: connect from 192.168.0.128 to null() Mar 30 16:02:13 Mediaserver rpcbind[23314]: connect from 192.168.0.128 to getport/addr(nfs) Mar 30 16:05:18 Mediaserver rpcbind[28349]: connect from 192.168.0.128 to null() Mar 30 16:05:18 Mediaserver rpcbind[28350]: connect from 192.168.0.128 to getport/addr(mountd) Mar 30 16:05:18 Mediaserver rpcbind[28351]: connect from 192.168.0.128 to null() Mar 30 16:05:18 Mediaserver rpcbind[28352]: connect from 192.168.0.128 to getport/addr(mountd) Mar 30 16:05:18 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.128:536 for /mnt/user/Pictures (/mnt/user/Pictures) Mar 30 16:05:18 Mediaserver rpcbind[28353]: connect from 192.168.0.128 to null() Mar 30 16:05:18 Mediaserver rpcbind[28354]: connect from 192.168.0.128 to getport/addr(nfs) Mar 30 16:08:15 Mediaserver rpcbind[629]: connect from 192.168.0.128 to null() Mar 30 16:08:15 Mediaserver rpcbind[630]: connect from 192.168.0.128 to getport/addr(mountd) Mar 30 16:08:15 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.128:541 for /mnt/user/Media (/mnt/user/Media) Mar 30 16:08:15 Mediaserver rpcbind[631]: connect from 192.168.0.128 to null() Mar 30 16:08:15 Mediaserver rpcbind[632]: connect from 192.168.0.128 to getport/addr(nfs) Mar 30 16:08:19 Mediaserver rpcbind[638]: connect from 192.168.0.64 to null() Mar 30 16:08:19 Mediaserver rpcbind[639]: connect from 192.168.0.64 to getport/addr(mountd) Mar 30 16:08:19 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.64:786 for /mnt/user/Media (/mnt/user/Media) Mar 30 16:08:19 Mediaserver rpcbind[640]: connect from 192.168.0.64 to null() Mar 30 16:08:19 Mediaserver rpcbind[641]: connect from 192.168.0.64 to getport/addr(nfs) Mar 30 16:18:55 Mediaserver rpcbind[18202]: connect from 192.168.0.128 to null() Mar 30 16:18:55 Mediaserver rpcbind[18203]: connect from 192.168.0.128 to getport/addr(mountd) Mar 30 16:18:55 Mediaserver rpc.mountd[8249]: authenticated mount request from 192.168.0.128:550 for /mnt/user/Media (/mnt/user/Media)

It should be mostly fine with VT-d disable, but they are also known for sometimes dropping disks without a reason, though they work more or less reliable for some, I would say it should be low risk to use for a little while.

Changed Status to Retest Changed Priority to Other

This is most likely a general support issue, you can try this to see if you can catch anything if it happens again.

Those errors are kind of strange, but the disk looks fine, if you haven't yet replace the SATA cable.

Have you swapped/replaced cables? SMART test should fail if the disk is really that bad.

Not good, Asmedia based controllers work fine, but they are 2 port controllers, anything Asmedia with more than two ports usually uses SATA port multiplier(s) and that's no good (there might be exceptions, I think I remember seeing one that used multiple 2 port Asmedia chipsets), if 5 ports are enough look for a JMB585 based controller, or look for an 8 port LSI HBA.

Correct, then parity needs to be re-synced.

Sounds like flash drive problems, you should post the diags. You just need to re-assign it.

Since there are actual read errors you should cancel the rebuild, shutdown and replace the cable, rebuild will then re-start from the beginning.