JorgeB

Diags are after rebooting so we can't see what happened, but disk looks fine.

Those messages are the start (cause) of the read errors, that then turn into write errors (on only one disk because Unraid only disables as many disks as there are parity devices. Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] Unaligned partial completion (resid=56, sector_sz=512) Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] tag#546 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] tag#546 Sense Key : 0x3 [current] Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] tag#546 ASC=0x11 ASCQ=0x0 Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] tag#546 CDB: opcode=0x88 88 00 00 00 00 01 06 66 d6 48 00 00 02 f0 00 00 Jun 9 05:48:00 Tower kernel: print_req_error: critical medium error, dev sde, sector 4402370120 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370056 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370064 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370072 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370080 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370088 Jun 9 05:48:00 Tower kernel: md: disk3 read error, sector=4402370096 Jun 9 05:48:18 Tower kernel: sd 1:1:0:1: [sdc] Unaligned partial completion (resid=16344, sector_sz=512) Jun 9 05:48:18 Tower kernel: sd 1:1:0:1: [sdc] tag#567 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jun 9 05:48:18 Tower kernel: sd 1:1:0:1: [sdc] tag#567 Sense Key : 0x3 [current] Jun 9 05:48:18 Tower kernel: sd 1:1:0:1: [sdc] tag#567 ASC=0x11 ASCQ=0x0 Jun 9 05:48:18 Tower kernel: sd 1:1:0:1: [sdc] tag#567 CDB: opcode=0x88 88 00 00 00 00 01 06 6b 24 08 00 00 04 00 00 00 Jun 9 05:48:18 Tower kernel: print_req_error: critical medium error, dev sdc, sector 4402652168 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652104 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652112 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652120 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652128 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652136 Jun 9 05:48:18 Tower kernel: md: disk1 read error, sector=4402652144

But are still using a RAID controller with a RAID driver, most likely wouldn't have the same problem with an LSI HBA.

Looks like you created a RAID volume with all 4 disks, you can create a RAID0 volume with each disk, that's done on the controller BIOS, but note that RAID controllers are not recommended for Unraid, you should use a regular HBA.

Diags are after rebooting so we can't see what happened, but disks look fine.

Same error on multiple disks: Jun 9 05:48:00 Tower kernel: sd 1:1:0:3: [sde] Unaligned partial completion (resid=56, sector_sz=512) Googling this it looks like it's a bug/firmware issue, there was a fixed for the standard Linux LSI driver, no idea about your HP RAID controller, note also that RAID controllers are not recommended for Unraid.

See here for some recovery options.

This should work, but you'd need to do a new config to re-assign parity as an array device, still probably best just to copy from one to another.

Try running in safe mode with all dockers/VMs stopped for a few days, if still issues you likely have a hardware problem.

No, you have 89% left.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?tab=comments#comment-511923

ATA2 appears to be failing bad, can't see witch drive that is only by that snippet.

You can try this, it might catch something, you can also try booting in safe mode.

I see macvlan call traces, those are usually related to having docker with custom IP address. You can also try booting in safe mode, and keeping dockers disable for a couple of days, if OK, start re-enabling everything one thing at a time.

It's never a good sign but if it remains stable it should be OK.

It doesn't think, it is. It's the only disk using USB. That's because it's now emulating the disk.

This disk that was assigned as disk7 is connected by USB: May 7 18:43:03 FULSERVE kernel: mdcmd (8): import 7 sda 64 7814026532 0 ST8000DM004-2CX188_ZCT0D23R May 7 18:43:03 FULSERVE kernel: md: import disk7: (sda) ST8000DM004-2CX188_ZCT0D23R size: 7814026532 May 7 18:43:03 FULSERVE kernel: md: disk7 new disk It was sda, after it dropped and got picked up again it became sdm.

It's up to you.

The error was logged like a disk problem, and likely resulted in the report uncorrectable attribute changing to 1, I would say a single error like this is no case for much concern, it can happen once and then not again for years, but if it keeps happening I would consider replacing the disk.

Yes.

Check the syslog and make sure there are no more of these: Jun 7 16:05:24 Alfred kernel: ata5.00: configured for UDMA/33 Jun 7 16:05:24 Alfred kernel: ata5: EH complete Jun 7 16:05:25 Alfred kernel: ata5.00: exception Emask 0x10 SAct 0x8303e00 SErr 0x4090000 action 0xe frozen Jun 7 16:05:25 Alfred kernel: ata5.00: irq_stat 0x00400040, connection status changed Jun 7 16:05:25 Alfred kernel: ata5: SError: { PHYRdyChg 10B8B DevExch } Jun 7 16:05:25 Alfred kernel: ata5.00: failed command: READ FPDMA QUEUED Jun 7 16:05:25 Alfred kernel: ata5.00: cmd 60/08:48:18:ec:00/00:00:00:00:00/40 tag 9 ncq dma 4096 in Jun 7 16:05:25 Alfred kernel: res 40/00:68:b0:f6:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jun 7 16:05:25 Alfred kernel: ata5.00: status: { DRDY } Jun 7 16:05:25 Alfred kernel: ata5.00: failed command: READ FPDMA QUEUED Jun 7 16:05:25 Alfred kernel: ata5.00: cmd 60/38:50:20:ec:00/05:00:00:00:00/40 tag 10 ncq dma 684032 in Jun 7 16:05:25 Alfred kernel: res 40/00:68:b0:f6:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jun 7 16:05:25 Alfred kernel: ata5.00: status: { DRDY } Jun 7 16:05:25 Alfred kernel: ata5.00: failed command: READ FPDMA QUEUED Jun 7 16:05:25 Alfred kernel: ata5.00: cmd 60/18:58:58:f1:00/00:00:00:00:00/40 tag 11 ncq dma 12288 in Jun 7 16:05:25 Alfred kernel: res 40/00:68:b0:f6:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jun 7 16:05:25 Alfred kernel: ata5.00: status: { DRDY } Jun 7 16:05:25 Alfred kernel: ata5.00: failed command: READ FPDMA QUEUED Jun 7 16:05:25 Alfred kernel: ata5.00: cmd 60/40:60:70:f1:00/05:00:00:00:00/40 tag 12 ncq dma 688128 in Jun 7 16:05:25 Alfred kernel: res 40/00:68:b0:f6:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jun 7 16:05:25 Alfred kernel: ata5.00: status: { DRDY }

dd is not a good way to test this, can you try doing a regular SMB transfer from your desktop (assuming using gigabit or better)?

User shares will always add some overhead, sometimes just a little, other times a lot, not exactly clear why some users see a much larger impact than others, add to that encryption on a CPU without AES support and it compounds the problem, example: You say copy to disk share with encryption is done at 84MB/s, without encryption you'll likely get close to gigabit line speed, 100MB/s+ (unless the disk is very old and slow), copying to the use share without encryption should also see a noticeable bump in performance, could be a little, could be a lot, like mentioned user share performance can vary a lot from user to user.

Use the latest release, upgrade should be straight forward, but always good to read the release notes.

Thanks for the update, that was my suspicion.