rainformpurple

Yeah, but that's the thing - how do I know parity was valid?

Gotcha. This is how it looks at the moment: Parity status: It picks up the pace every now and then before dropping back down to sub-30KB/sec speeds. I'm afraid that I have more disks on the way out, so I think I'll buy a set of new 18TB drives to replace these once this situation is sorted. My understanding of the coming events would be: Unassign disk1 Replace disk1 Let parity rebuild disk1 Then, when the times comes to replace the disks: Unassign parity disk Replace parity disk with new 18TB drive Rebuild parity Replace array disk1 with larger disk, let rebuild from parity (or attach one new drive as unassigned device, copy everything over, replace the disk and manually copy it back onto the new disk1) Move data from disk2 to disk1 Replace disk2 with larger disk Move data from disk3 and disk4 to disks 1 and 2 Replace disks 3 and 4 with larger ones Move data from disks 5, 6 and 7 to disks 1, 2, 3 and 4 Replace disks 5, 6 and 7 Run unbalance plugin to spread data evenly across drives I like moving things around myself so that I know what's going on, and that probably interferes with some ways Unraid prefers to do things, and I don't know which way is better - rebuilding from parity sounds like it'll take a very long time and copying the data manually sounds like it'll be faster. Maybe it won't.

The disk is still present in the system and is occasionally responding to commands, so it's not completely gone yet. I can also browse the disk's contents directly via /mnt/disk1, which is good. I have a spare 6TB disk of the same type that I bought probably a year ago "just to make sure", so once I feel confident that the disk's contents are able to be rebuilt, I'm ready to swap them.

How do I know if the parity is valid, then? Just wait for the parity check to complete? The last parity check was 2 months ago and that passed with no errors, not even read errors on disk 1. Granted, disk 1 has reported read errors at a few occasions and that prompted me to buy a spare drive, but the errors went away and everything seemed fine until now. I also enabled the SAS spindown plugin a while back, which is probably what killed the drive now. Oh, the irony.

If I stop the parity check, will I be able to rebuild the failing drive from parity? The check drags on and I don't think it will ever finish, and the performance hit is affecting everything on the server.

So I poked around a bit in the syslog and it seems that disk1 is on its way out: Mar 6 17:24:41 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:27:04 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:30:45 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:33:10 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:39:13 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:43:52 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:47:03 aram kernel: sd 1:0:1:0: [sdc] tag#228 CDB: opcode=0x88 88 00 00 00 00 02 98 52 4b b0 00 00 02 00 00 00 Mar 6 17:47:03 aram kernel: sd 1:0:1:0: [sdc] tag#217 CDB: opcode=0x88 88 00 00 00 00 02 98 52 49 b0 00 00 02 00 00 00 Mar 6 17:48:29 aram kernel: sd 1:0:1:0: [sdc] tag#217 OCR is requested due to IO timeout!! Mar 6 17:48:29 aram kernel: sd 1:0:1:0: [sdc] tag#217 SCSI host state: 5 SCSI host busy: 2 FW outstanding: 0 Mar 6 17:48:29 aram kernel: sd 1:0:1:0: [sdc] tag#217 scmd: (0x00000000d20e7c46) retries: 0x0 allowed: 0x5 Mar 6 17:48:29 aram kernel: sd 1:0:1:0: [sdc] tag#217 CDB: opcode=0x88 88 00 00 00 00 02 98 52 49 b0 00 00 02 00 00 00 Mar 6 17:48:29 aram kernel: megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 Mar 6 17:48:29 aram kernel: megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000 Mar 6 17:49:46 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:53:22 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:56:18 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#421 CDB: opcode=0x88 88 00 00 00 00 02 98 53 45 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#420 CDB: opcode=0x88 88 00 00 00 00 02 98 53 4d 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#419 CDB: opcode=0x88 88 00 00 00 00 02 98 53 57 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#418 CDB: opcode=0x88 88 00 00 00 00 02 98 53 53 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#417 CDB: opcode=0x88 88 00 00 00 00 02 98 53 49 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#416 CDB: opcode=0x88 88 00 00 00 00 02 98 53 51 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#414 CDB: opcode=0x88 88 00 00 00 00 02 98 53 43 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#413 CDB: opcode=0x88 88 00 00 00 00 02 98 53 47 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#412 CDB: opcode=0x88 88 00 00 00 00 02 98 53 4b 90 00 00 02 00 00 00 Mar 6 17:57:55 aram kernel: sd 1:0:1:0: [sdc] tag#411 CDB: opcode=0x88 88 00 00 00 00 02 98 53 55 90 00 00 02 00 00 00 Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 OCR is requested due to IO timeout!! Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 SCSI host state: 5 SCSI host busy: 10 FW outstanding: 10 Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 scmd: (0x00000000b70a797a) retries: 0x1 allowed: 0x5 Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 CDB: opcode=0x88 88 00 00 00 00 02 98 53 55 90 00 00 02 00 00 00 Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 Request descriptor details: Mar 6 17:58:50 aram kernel: sd 1:0:1:0: [sdc] tag#411 RequestFlags:0xc MSIxIndex:0x3 SMID:0x19c LMID:0x0 DevHandle:0x11 Mar 6 17:58:50 aram kernel: IO request frame: Mar 6 17:58:50 aram kernel: 00000000: 00000011 00000000 00000000 ffc69a20 00600002 00000020 00000000 00040000 Mar 6 17:58:50 aram kernel: 00000020: 00000000 00004010 00000000 00000000 00000000 00000000 00000000 02000000 Mar 6 17:58:50 aram kernel: 00000040: 00000088 53980200 00009055 00000002 00000000 00000000 00000000 00000000 Mar 6 17:58:50 aram kernel: 00000060: 005b0000 00010000 00000000 00000000 00000000 00000000 00004010 00000000 Mar 6 17:58:50 aram kernel: 00000080: a3a80000 00000000 00001000 00000000 a3a81000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000a0: a3a82000 00000000 00001000 00000000 a3a83000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000c0: a3a84000 00000000 00001000 00000000 a3a85000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000e0: a3a86000 00000000 00001000 00000000 ffac4000 00000000 00000390 80000000 Mar 6 17:58:50 aram kernel: Chain frame: Mar 6 17:58:50 aram kernel: 00000000: a3a87000 00000000 00001000 00000000 a3a88000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000020: a3a89000 00000000 00001000 00000000 a3a8a000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000040: a3a8b000 00000000 00001000 00000000 a3a8c000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000060: a3a8d000 00000000 00001000 00000000 a3a8e000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000080: a3a8f000 00000000 00001000 00000000 a3a90000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000a0: a3a91000 00000000 00001000 00000000 a3a92000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000c0: a3a93000 00000000 00001000 00000000 a3a94000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000000e0: a3a95000 00000000 00001000 00000000 a3a96000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000100: a3a97000 00000000 00001000 00000000 a3a98000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000120: a3a99000 00000000 00001000 00000000 a3a9a000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000140: a3a9b000 00000000 00001000 00000000 a3a9c000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000160: a3a9d000 00000000 00001000 00000000 a3a9e000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000180: a3a9f000 00000000 00001000 00000000 a3aa0000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000001a0: a3aa1000 00000000 00001000 00000000 a3aa2000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000001c0: a3aa3000 00000000 00001000 00000000 a3aa4000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000001e0: a3aa5000 00000000 00001000 00000000 a3aa6000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000200: a3aa7000 00000000 00001000 00000000 a3aa8000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000220: a3aa9000 00000000 00001000 00000000 a3aaa000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000240: a3aab000 00000000 00001000 00000000 a3aac000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000260: a3aad000 00000000 00001000 00000000 a3aae000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000280: a3aaf000 00000000 00001000 00000000 a3ab0000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000002a0: a3ab1000 00000000 00001000 00000000 a3ab2000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000002c0: a3ab3000 00000000 00001000 00000000 a3ab4000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 000002e0: a3ab5000 00000000 00001000 00000000 a3ab6000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000300: a3ab7000 00000000 00001000 00000000 a3ab8000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000320: a3ab9000 00000000 00001000 00000000 a3aba000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000340: a3abb000 00000000 00001000 00000000 a3abc000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000360: a3abd000 00000000 00001000 00000000 a3abe000 00000000 00001000 00000000 Mar 6 17:58:50 aram kernel: 00000380: a3abf000 00000000 00001000 40000000 00000000 00000000 00000000 00000000 Mar 6 17:58:50 aram kernel: 000003a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 17:58:50 aram kernel: 000003c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 17:58:50 aram kernel: 000003e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 17:58:50 aram kernel: megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 Mar 6 17:58:50 aram kernel: megaraid_sas 0000:03:00.0: [ 0]waiting for 10 commands to complete for scsi1 Mar 6 17:58:55 aram kernel: megaraid_sas 0000:03:00.0: [ 5]waiting for 9 commands to complete for scsi1 Mar 6 17:59:00 aram kernel: megaraid_sas 0000:03:00.0: [10]waiting for 8 commands to complete for scsi1 Mar 6 17:59:06 aram kernel: megaraid_sas 0000:03:00.0: [15]waiting for 6 commands to complete for scsi1 Mar 6 17:59:11 aram kernel: megaraid_sas 0000:03:00.0: [20]waiting for 6 commands to complete for scsi1 Mar 6 17:59:16 aram kernel: megaraid_sas 0000:03:00.0: [25]waiting for 5 commands to complete for scsi1 Mar 6 17:59:21 aram kernel: megaraid_sas 0000:03:00.0: [30]waiting for 5 commands to complete for scsi1 Mar 6 17:59:26 aram kernel: megaraid_sas 0000:03:00.0: [35]waiting for 4 commands to complete for scsi1 Mar 6 17:59:31 aram kernel: megaraid_sas 0000:03:00.0: [40]waiting for 3 commands to complete for scsi1 Mar 6 17:59:36 aram kernel: megaraid_sas 0000:03:00.0: [45]waiting for 2 commands to complete for scsi1 Mar 6 17:59:41 aram kernel: megaraid_sas 0000:03:00.0: [50]waiting for 2 commands to complete for scsi1 Mar 6 17:59:47 aram kernel: megaraid_sas 0000:03:00.0: [55]waiting for 1 commands to complete for scsi1 Mar 6 17:59:49 aram kernel: megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000 Mar 6 18:01:56 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 18:02:29 aram kernel: sd 1:0:1:0: [sdc] tag#431 OCR is requested due to IO timeout!! Mar 6 18:02:29 aram kernel: sd 1:0:1:0: [sdc] tag#431 SCSI host state: 5 SCSI host busy: 4 FW outstanding: 0 Mar 6 18:02:29 aram kernel: sd 1:0:1:0: [sdc] tag#431 scmd: (0x00000000b70a797a) retries: 0x2 allowed: 0x5 Mar 6 18:02:29 aram kernel: sd 1:0:1:0: [sdc] tag#431 CDB: opcode=0x88 88 00 00 00 00 02 98 53 55 90 00 00 02 00 00 00 Mar 6 18:02:29 aram kernel: megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 Mar 6 18:02:29 aram kernel: megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000 Mar 6 18:04:09 aram kernel: sd 1:0:1:0: [sdc] tag#468 CDB: opcode=0x88 88 00 00 00 00 02 98 53 b7 90 00 00 02 00 00 00 Mar 6 18:04:09 aram kernel: sd 1:0:1:0: [sdc] tag#467 CDB: opcode=0x88 88 00 00 00 00 02 98 53 a5 90 00 00 02 00 00 00 Mar 6 18:04:09 aram kernel: sd 1:0:1:0: [sdc] tag#466 CDB: opcode=0x88 88 00 00 00 00 02 98 53 9f 90 00 00 02 00 00 00 Mar 6 18:04:09 aram kernel: sd 1:0:1:0: [sdc] tag#465 CDB: opcode=0x88 88 00 00 00 00 02 98 53 a3 90 00 00 02 00 00 00 Mar 6 18:04:09 aram kernel: sd 1:0:1:0: [sdc] tag#464 CDB: opcode=0x88 88 00 00 00 00 02 98 53 a1 90 00 00 02 00 00 00 Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 OCR is requested due to IO timeout!! Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 SCSI host state: 5 SCSI host busy: 9 FW outstanding: 8 Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 scmd: (0x00000000415c5b1d) retries: 0x1 allowed: 0x5 Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 CDB: opcode=0x88 88 00 00 00 00 02 98 53 a1 90 00 00 02 00 00 00 Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 Request descriptor details: Mar 6 18:04:26 aram kernel: sd 1:0:1:0: [sdc] tag#464 RequestFlags:0xc MSIxIndex:0x3 SMID:0x1d1 LMID:0x0 DevHandle:0x11 Mar 6 18:04:26 aram kernel: IO request frame: Mar 6 18:04:26 aram kernel: 00000000: 00000011 00000000 00000000 ffc6ae00 00600002 00000020 00000000 00040000 Mar 6 18:04:26 aram kernel: 00000020: 00000000 00004010 00000000 00000000 00000000 00000000 00000000 02000000 Mar 6 18:04:26 aram kernel: 00000040: 00000088 53980200 000090a1 00000002 00000000 00000000 00000000 00000000 Mar 6 18:04:26 aram kernel: 00000060: 005b0000 00010000 00000000 00000000 00000000 00000000 00004010 00000000 Mar 6 18:04:26 aram kernel: 00000080: a0ac0000 00000000 00001000 00000000 a0ac1000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000a0: a0ac2000 00000000 00001000 00000000 a0ac3000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000c0: a0ac4000 00000000 00001000 00000000 a0ac5000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000e0: a0ac6000 00000000 00001000 00000000 ffa8f000 00000000 00000390 80000000 Mar 6 18:04:26 aram kernel: Chain frame: Mar 6 18:04:26 aram kernel: 00000000: a0ac7000 00000000 00001000 00000000 a0ac8000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000020: a0ac9000 00000000 00001000 00000000 a0aca000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000040: a0acb000 00000000 00001000 00000000 a0acc000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000060: a0acd000 00000000 00001000 00000000 a0ace000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000080: a0acf000 00000000 00001000 00000000 a0ad0000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000a0: a0ad1000 00000000 00001000 00000000 a0ad2000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000c0: a0ad3000 00000000 00001000 00000000 a0ad4000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000000e0: a0ad5000 00000000 00001000 00000000 a0ad6000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000100: a0ad7000 00000000 00001000 00000000 a0ad8000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000120: a0ad9000 00000000 00001000 00000000 a0ada000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000140: a0adb000 00000000 00001000 00000000 a0adc000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000160: a0add000 00000000 00001000 00000000 a0ade000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000180: a0adf000 00000000 00001000 00000000 a0ae0000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000001a0: a0ae1000 00000000 00001000 00000000 a0ae2000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000001c0: a0ae3000 00000000 00001000 00000000 a0ae4000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000001e0: a0ae5000 00000000 00001000 00000000 a0ae6000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000200: a0ae7000 00000000 00001000 00000000 a0ae8000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000220: a0ae9000 00000000 00001000 00000000 a0aea000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000240: a0aeb000 00000000 00001000 00000000 a0aec000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000260: a0aed000 00000000 00001000 00000000 a0aee000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000280: a0aef000 00000000 00001000 00000000 a0af0000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000002a0: a0af1000 00000000 00001000 00000000 a0af2000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000002c0: a0af3000 00000000 00001000 00000000 a0af4000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 000002e0: a0af5000 00000000 00001000 00000000 a0af6000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000300: a0af7000 00000000 00001000 00000000 a0af8000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000320: a0af9000 00000000 00001000 00000000 a0afa000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000340: a0afb000 00000000 00001000 00000000 a0afc000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000360: a0afd000 00000000 00001000 00000000 a0afe000 00000000 00001000 00000000 Mar 6 18:04:26 aram kernel: 00000380: a0aff000 00000000 00001000 40000000 00000000 00000000 00000000 00000000 Mar 6 18:04:26 aram kernel: 000003a0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 18:04:26 aram kernel: 000003c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 18:04:26 aram kernel: 000003e0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 6 18:04:26 aram kernel: megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 Mar 6 18:04:26 aram kernel: megaraid_sas 0000:03:00.0: [ 0]waiting for 8 commands to complete for scsi1 Mar 6 18:04:31 aram kernel: megaraid_sas 0000:03:00.0: [ 5]waiting for 4 commands to complete for scsi1 Mar 6 18:04:36 aram kernel: megaraid_sas 0000:03:00.0: [10]waiting for 1 commands to complete for scsi1 Mar 6 18:04:37 aram kernel: megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000 Mar 6 18:06:23 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 18:09:29 aram kernel: sd 1:0:1:0: [sdc] tag#408 CDB: opcode=0x88 88 00 00 00 00 02 98 54 43 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#407 CDB: opcode=0x88 88 00 00 00 00 02 98 54 51 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#405 CDB: opcode=0x88 88 00 00 00 00 02 98 54 4f 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#402 CDB: opcode=0x88 88 00 00 00 00 02 98 54 4d 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#401 CDB: opcode=0x88 88 00 00 00 00 02 98 54 4b 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#400 CDB: opcode=0x88 88 00 00 00 00 02 98 54 49 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#399 CDB: opcode=0x88 88 00 00 00 00 02 98 54 47 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#398 CDB: opcode=0x88 88 00 00 00 00 02 98 54 45 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#200 CDB: opcode=0x88 88 00 00 00 00 02 98 54 53 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#208 CDB: opcode=0x88 88 00 00 00 00 02 98 54 55 90 00 00 02 00 00 00 Mar 6 18:09:49 aram kernel: sd 1:0:1:0: [sdc] tag#216 CDB: opcode=0x88 88 00 00 00 00 02 98 54 57 90 00 00 02 00 00 00 Mar 6 18:09:50 aram kernel: sd 1:0:1:0: [sdc] tag#224 CDB: opcode=0x88 88 00 00 00 00 02 98 54 59 90 00 00 02 00 00 00 Mar 6 18:10:01 aram kernel: sd 1:0:1:0: [sdc] tag#196 CDB: opcode=0x88 88 00 00 00 00 02 98 54 5b 90 00 00 02 00 00 00 Mar 6 18:10:12 aram kernel: sd 1:0:1:0: Power-on or device reset occurred Mar 6 18:10:23 aram kernel: sd 1:0:1:0: [sdc] tag#196 OCR is requested due to IO timeout!! Mar 6 18:10:23 aram kernel: sd 1:0:1:0: [sdc] tag#196 SCSI host state: 5 SCSI host busy: 13 FW outstanding: 0 Mar 6 18:10:23 aram kernel: sd 1:0:1:0: [sdc] tag#196 scmd: (0x000000005fb8537f) retries: 0x0 allowed: 0x5 Mar 6 18:10:23 aram kernel: sd 1:0:1:0: [sdc] tag#196 CDB: opcode=0x88 88 00 00 00 00 02 98 54 5b 90 00 00 02 00 00 00 Mar 6 18:10:23 aram kernel: megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009 Mar 6 18:10:23 aram kernel: megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000 Well, this is new and exciting! What are the odds that the parity check will complete before the disk gives up the ghost completely? Complete diagnostics attached. aram-diagnostics-20230306-2047.zip

Hi all, Sunday morning at 1:30am, the parity check started. Now, Monday evening, it's still going and it doesn't look like it's going to be done anytime soon: DIsk 1 was reported to have read errors, which it kinda has had for several months, but I just haven't had the time to swap the disk out. I guess that time is approaching fast... Usually, the parity check takes somewhere between 11,5 and 13,5 hours, which is fine and expected for the parity size and the disks being spinning rust, but this is just ridiculous. What may cause this? My understanding is that the parity calculation starts with disk 1 and works its way through the disks in the array, but I'm probably mistaken. In any case, it seems that something is afoot and I can't figure out why. System: Dell PowerEdge T430, 144GB RAM, 2xXeon E5-2640 v3 8c16t (16c/32t). 8xHGST Ultrastar 6TB drives in array. 250GB cache disk for docker container data. 512GB NVMe SSD for downloads. 2TB SATA SSD for VMs. Unraid 6.9.2 Pro. There are a quite a few docker containers and VMs running. The VMs have a dedicated disk, the docker containers have a dedicated disk for the docker data, but some of them download and write data to the array (via the cache disk) when Mover runs every night. The data is stored temporarily on a dedicated SSD just for downloads until Mover runs. I'm assuming that such write activity will impact the duration of the parity check as things need to be recalculated, but 57-58 days for a parity check seems somewhat egregrious. As I'm planning to replace disk 1 soon, I don't want to stop the parity check as I need that parity when the disk contents are to be rebuilt after the disk replacement. Will stopping the docker services help in this situation?

Okay, thanks. Manual patching it is, then.

I don't see this plugin in Community Apps. I'm on 6.9.2. Can it be manually installed from somewhere?

Noone? Anyone? Is more information required? If so, please tell me what you need and I'll do my best to provide it.

144GB, 40% utilization. I'm running a few VMs and lots of docker containers, plus it's nice to not have to worry about having enough memory if I should decide to spin up more VMs. I also have a backup server (which is for backups, really), with 64GB RAM. It runs plain Ubuntu Server at the moment, and my only plan for this server is to throw more disks at it.

Hi, I'm preparing to upgrade to 6.11.5, but I have some weird issues with my server that I'd like to try and sort out before I do. I've had the issues for a while, and I think they started after the log went full and strange things started happening. The GUI was unresponsive, the Docker page didn't work, Settings page didn't work, VM page didn't work - but all the Docker Containers worked and all the VMs worked. I decided to manually delete system.log.1 from the system to free up space, only to realize it was stored in ram and it didn't really matter at all, but at least the WebUI became a bit more responsive. I then rebooted the server after a while when I had time to deal with any issues on boot, but to my surprise there were none. After a while I noticed that I no longer had the choice of "Custom : br0" as a network in my Docker settings, which means I no longer can assign static IP addresses with my local network range. I also can't collect diagnostics from the WebUI, but I was able to do so via the command line. Is this a sign of a dying flash drive, or is something else afoot? Diagnostics attached. aram-diagnostics-20230115-1940.zip

Hi all, I'm not sure if this is an unRAID problem, Linux Mint problem or KVM problem, but as the VM runs on unRAID I figured I'd try here first. Last weekend, I upgraded my unRAID server and installed an extra CPU, more RAM, a USB controller, a wifi/bluetooth card and an AMD Radeon HD 8570 GPU, and then migrated my physical HTPC to a VM. The GPU, USB controller and wifi/BT card were passed through to the VM and everything mostly works. The first problem I encountered was that playing videos in VLC yielded no video, only audio. That was fixed by setting the decoding to Xvideo in the VLC settings. The second problem was that the screen saver kicked in after 15 minutes, locking the screen. That was fine, the system worked perfectly after moving the mouse; I was let back into Mint no worries. However, if the system was left for another 15 minutes, Mint turned the screen off. When trying to wake the system back up by moving the mouse, the screen turns back on, but the keyboard was unresponsive. I can move the mouse cursor, but can't click anything. There are also minor graphical glitches in the display output. A CTRL-ALT-Backspace will kill and restart the X server, and then everything works. The downside to this approach is that all open programs are also killed and need to be restarted, which, for a HTPC isn't much (Firefox and VLC, usually). The major downside is that the other members of my family sees this as "Linux is unstable", "The setup isn't working" and thus the onus is on me to fix this post-haste, as "the old HTPC just worked for years" - which is true; the old system was set up with Mint in 2016 and hasn't skipped a beat (except that one time I uninstalled the display manager by accident...). Yesterday, I changed the power settings in Mint to never turn off the screen, and I haven't heard anything from home indicating that the HTPC has locked up. Has anyone seen similar behaviour/problems before and if so, how did you fix them?

Followup to this one: uTorrent 2.2.1 was old, insecure and slow and started crashing on me. Additionally, it didn't really play that well with {son,rad,lid}arr, so in the end I ripped it out and took the time to set up qBittorrent properly. Now everything works perfectly.

Yeah, everything's been quite normal, and the weather's been cooler, too. Now that it's getting warmer outside, naturally the inside temps rise as well, which sort of explains what I'm seeing, but I don't want to lose 20TB data just because summer's coming. And turning the server off for 4-5 months isn't really an option either... I'll turn down the heat when I get home and see if I can get away with that (fiancee thinks ambient temperatures below 25 deg C are "cold"), otherwise I have a problem. I don't really have anywhere else to put the server than where it's sitting at the moment.

Hi all, Over the last week, I've been getting lots of reports from my server that the disks are hot, regularly reaching 46-47 degrees C. After a while, they return to "not hot", but they are still above 40 degrees. I'm starting to worry about the longevity of the disks and whether this is a big problem or not. I know disks prefer below 40 degrees, but the server is sitting in my living room. With spring finally arriving and ever-increasing temperatures outside and inside, I need to know if I'm looking at an impending disaster. I have an array of 8 HGST 7K6 SAS3 6TB disks, with single parity. Single cache disk, Samsung 850 EVO 256GB SSD. Server is a Dell PowerEdge T430, currently single CPU (passively cooled with heatsink), 1x 140mm fan at the back. I could possibly install a second fan to help increase the airflow, but as this is a Dell server, there aren't many options to install extra cooling. My plans for this server were to upgrade to dual CPU, more memory, pop in two graphics cards for VM passthrough, a wifi/bluetooth card and a USB controller, but now I'm concerned that the extra components will introduce so much extra heat that the disks will constantly be hot and fail prematurely.

Since I'll be using it for my secondary internal storage enclosure with unRAID, I don't need the RAID functionality. That's excellent, thanks again!

In that case I might as well pick up a 9211-8I and save a few bucks. Thanks.

Coincidentally, I'm looking at the HUS726T6TALE6L4 and HUS726T6TALN6L4 drives, and as far as I can tell, the only difference between them is NOK 50 in price and that the HUS726T6TALE6L4 is a 512e drive and the HUS726T6TALN6L4 is a 4Kn drive. The cost difference is negligible for a 4-drive purchase, but I'd like to get the better performer of the two if there even is a "better" rather than just "slightly different". The E drive is 512e sector aligned and emulates 4K sectors, and the N drive is 4K natively sector aligned. For just storage, will I even see a difference in performance either way I go as long as they are all the same and the drives aren't SMR (which they aren't)? With regards to controller support, I read that some controllers don't support 4kN drives as the technology is "too new", but my understanding is that it's been supported in Linux since 2009 (kernel 2.6.31+). Will an LSI 9240-8i HBA (PCIe2 x8) work?

No, as there were no uTorrent containers available in Apps, I had to create my own template and got the unRAID Docker manager thing to pull an image from dockerhub. I then added paths and ports to it and made it work that way. After changing the settings of the container template I made and with a subsequent restart of the container, however, the changes within the container were blown away. So I added the webui.zip file to it again, committed the changes, somehow made a new image, created a dockerhub account, pushed my image there, changed my unRAID container to use my image, updated it and IT BLOODY WORKS! HAHA! I have no idea what I did, but it works. Probably not the best starting point, but there you go.

After messing around with docker and understanding absolutely nothing, I somehow managed to get the new webui.zip file copied into the container. The change now sticks and everything still works, so I'm going to leave it alone before I make the universe implode.

It seems the "easiest" way is to create my own docker image, push it to dockerhub and then create my container based on that image. Is there an unRAID specific way to do this for it to work with unRAID, or can I create it on any Linux computer?

Right, but utserver looks for the webui.zip file in /var/local/utserver, and the settings directory is /var/local/utserver/settings... How hard would the container break if I map the settings directory to /var/local/utserver, seeing as that's where the binary and everything lives? Edit: The answer: Brutally. docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: "/var/local/utserver/utserver": stat /var/local/utserver/utserver: no such file or directory": unknown. So essentially that means I still need to be able to somehow make changes to the container and commit them to make them stick.

Hi, New to the unRAID universe and docker containers, so I'm probably just not experienced enough yet. Anyway: I have created a uTorrent container because I don't like Deluge, qBittorrent and can't get rTorrent to work. I did get the uTorrent container to work on the first try, so there's that. In any case, the included webui.zip contains a slightly broken version of the uTorrent webui and as such I'd like to change that for a version that isn't broken. I downloaded the webui.zip file into the container and did a hard refresh of the web page, and everything works fine until I restart the container. After the restart, the old slightly-broken webui is back. Given how containers work I guess that's to be expected, but I can't figure out how to make my changes stick. I found a page talking about having to commit the changes, which I don't know how I would go about doing. Another thing is whether the changes I make be submitted to the original container image at hub.docker.com, or if they will remain local to my server? As I said, it works fine except for the included webui. Any help and/or pointers to how to do this are most appreciated.