JorgeB

Disk is sdc, sda is this: Jul 1 03:52:49 Tower kernel: scsi 1:0:0:0: Direct-Access WD Elements 25A3 1030 PQ: 0 ANSI: 6 Jul 1 03:52:49 Tower kernel: sd 1:0:0:0: Attached scsi generic sg0 type 0 Jul 1 03:52:49 Tower kernel: sd 1:0:0:0: [sda] Unit Not Ready Maybe you left the USB enclosure connected?

It's still rebuilding the disk but it started over because of the scheduled check, not sure this is ab bug or plugin related, you'd first need to see if the same happens without the plugin.

Disk looks OK, run an extended SMART test and if it passes replace/swap cables to rule that out and try again.

In a general storage/Windows forum. BTW, a couple of common issues with SAS devices: -formatted with a custom sector size, Windows and most OSes can only use 512 or 4096, needs to be reformatted with common sector size. -formatted with type 1 or type 2 protection, this need to be removed. SMART report will show both of the above, e.g.: == START OF INFORMATION SECTION === Vendor: xxx Product: xxx Revision: NE02 Compliance: SPC-4 User Capacity: 1,800,360,124,416 bytes [1.80 TB] Logical block size: 512 bytes Physical block size: 4096 bytes Formatted with type 2 protection Smartmontools is also available for Windows.

Sorry, can't really help with that, try Google, but until protection is removed devices won't work.

This forum is about Unraid OS, not Windows, I didn't notice before you were talking about Windows, not the right forum to be posting about that, though someone might still be able to help you're more likely to get help if you post in a more appropriate forum.

Please post the diagnostics: Tools -> Diagnostics

That script is not needed for that controller, it has however known issues with Unraid and is not recommended, but if the drives are not being detected this works for some: https://forums.unraid.net/bug-reports/stable-releases/disks-missing-after-upgrading-to-670-r536/?do=findComment&comment=4583

Forgot I saved this link https://forums.unraid.net/topic/93432-parity-disk-read-errors/?do=findComment&comment=864067 sg3_utils can be installed with the nerd pack plugin.

Formatted with type 2 protection Disks are formatted with type2 protection, if you Google that you'll find how to remove it.

Please post the diagnostics: Tools -> Diagnostics

There are some recovery options here, first one to try for this would be the one with "ro,notreelog,nologreplay".

That's a MegaRIAD model, usually not flashable to IT mode, look for a regular HBA instead.

Can confirm this is an issue with 4Kn devices formatted with xfs, Unraid reports the device as 512B at mkfs time and that's what xfs uses, then it won't mount when it detects the device is really 4Kn (curiously it's not an issue with btrfs), you should make a bug report: https://forums.unraid.net/bug-reports/stable-releases/ P.S. there's no way I see of fixing an existing filesystem, but for a new xfs filesystem and until the issue is fixed you can add -s size=4096 to mkfs to get around the problem, e.g.: mkfs.xfs -m crc=1,finobt=1 -s size=4096 -f /dev/md#

After a quick look at the syslog only thing I see out of the ordinary is an nf_conntrack call trace, see if this applies to you: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

That was the main culprit, but post new diags if there are more issues.

Jun 28 19:36:41 Tower kernel: Bluetooth: hci0: Reading Intel version information failed (-22) Jun 28 19:36:41 Tower kernel: Bluetooth: hci0: Intel Read version failed (-22) Jun 28 19:36:41 Tower kernel: Bluetooth: hci0: Intel reset sent to retry FW download If not in use try disabling it in the board BIOS.

Like mentioned that would be the first thing you should try, still looks like a spin up related error, these disks spun down: Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdk Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdd Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdj Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdc Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdo Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdl Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdq Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdn Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdb Jun 29 23:06:05 r720 SAS Assist v0.85: Spinning down device /dev/sdp Then CA backup ran: Jun 30 02:01:15 r720 CA Backup/Restore: Backing Up appData from /mnt/user/appdata/ to /[email protected] And woke up the disks, note that the problem was in the same 10 disks that were spun down before: Jun 30 02:01:20 r720 kernel: sd 7:0:0:0: [sdb] tag#6560 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:1:0: [sdc] tag#6561 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:8:0: [sdj] tag#6563 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:10:0: [sdl] tag#6565 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:13:0: [sdo] tag#6567 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:15:0: [sdq] tag#6569 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:2:0: [sdd] tag#6562 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:9:0: [sdk] tag#6564 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:14:0: [sdp] tag#6568 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Jun 30 02:01:20 r720 kernel: sd 7:0:12:0: [sdn] tag#6566 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s

Please use the existing plugin support thread:

Those small reads are normal when the disks are spun up, it's to get SMART stats, they shouldn't be the reason the disks are spinning up.

See below, it usually only applies to the ST8000VN004, still worth checking:

Since this is plugin related please use the existing plugin support thread:

Please use the existing UD support thread to discuss any related issues:

It's not, it might be related to spin down, i.e., problem occurs when the drives wake up, e.g., when the mover wakes them up to run.

See if disabling spin down helps with the drives getting disabled, also make sure just one cable goes to the MD1200, Unraid doesn't support SAS multi-path, these errors are likely the result of that: Jun 29 07:30:40 r720 emhttpd: device /dev/sdt problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sdz problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sdu problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sdr problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sdx problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sdv problem getting id Jun 29 07:30:40 r720 emhttpd: device /dev/sds problem getting id Jun 29 07:30:41 r720 emhttpd: device /dev/sdah problem getting id Jun 29 07:30:41 r720 emhttpd: device /dev/sdy problem getting id Jun 29 07:30:41 r720 emhttpd: device /dev/sdal problem getting id