JorgeB

Already did, 2 posts above

I guess that could happen if there was no data on the rebuilt disk sectors where there were read errors before, that's the only way it would make sense to me.

Without either read errors on disk2 or sync errors? One or the other would be expected.

https://www.sybausa.com/index.php?route=product/product&path=64_205&product_id=901

You need to try and find out what chipset it uses, doesn't look like a Marvell but difficult to say for sure by the pics, anything Asmedia based would be OK.

You're having issues with the flash drive: Sep 15 14:20:41 Ket kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Sep 15 14:20:41 Ket kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current] Sep 15 14:20:41 Ket kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0 Sep 15 14:20:41 Ket kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 03 08 00 00 f0 00 Sep 15 14:20:41 Ket kernel: print_req_error: I/O error, dev sda, sector 776 Disk sdg appears to be suffering from a connection problem, replace cables, as for the PCIe errors they are usually OK, but can flood the log, a bios update or using another PCIe slot can help, if not try this.

Removing disk8 with a known bad disk is not a good option, you should use a new disk to replace disk2.

It's me who suspects both issues are related, don't know what Tom thinks about that.

They were on continuous sectors, and each sector in this case is 512 bytes, so just a little data, if you have mostly media files it will most likely translate to a little glitch during playback on a single file. I would first replace disk2 then add dual parity later, you can't do it at the same time.

Just to add that while Tom mentioned they are trying to fix this issue for v6.8-rc1, I suppose that if it takes longer than expected, or if for example the SQL corruption issue is unrelated and fixed before this, I would expect they could release rc1 with this as a known issue.

Don't remember that. Problem free yes, always was AFAIK, suggested depends most on array size, but I say it's a very small price to pay for the added redundancy even for smaller arrays, and yes it would save you from a situation like this in the future. You can try rebuilding again, but disk2 appears to be failing so likely it will have the same or even more errors. You don't want to run a correcting check with a known bad disk, can corrupt parity. Replace disk2, only way to found out which files are affected on disk1 would require you had created cheksums before this, or be using btrfs.

Yes, by Tom.

Unless you had dual parity, if there are errors on another disk during a rebuild there will be some corruption, unless you were lucky and there wasn't any data on those sectors.

This meas it's not a filesystem problem, it means the partition layout doesn't conform to Unraid's requirements, this happens mostly when moving from a raid controller to a standard HBA, or vice-versa.

LT is trying to fix this issue for v6.8rc1, which will be released soon™

That's a good option, they are known to work great with Unraid.

It's a hardware problem, either board (assuming it's not on a PCIe adapter) or the NVMe device.

Unclean status is reset after every reboot, doesn't matter if you do or don't cancel the parity check, if an unclean shutdown is detect at boot it means the previous shutdown wasn't clean.

Can't see what's the problem without the diags.

Redundancy is not a backup, also if the pool was created on v6.7.x it wasn't redundant because of a bug. Please post the diagnostics: Tools -> Diagnostics

Yeah, it's a shame Crucial doesn't fix this, I read in another forum some bulshit answer from their support saying it's normal, but in that case every other Crucial SSD should have the same issue and they don't.

That's not normal with v6.6, you might want to start a support thread and post diags.

That's about normal for default write mode, you can try turbo write.

this

Looks like a problem with the Marvell controller, don't use those 2 ports.