JorgeB

https://wiki.unraid.net/Shrink_array

Cache filesystem is corrupt, best bet is to backup and re-format.

This issue has usually been linked with other things interacting with /mnt/user, like a docker that directly manipulate files, e.g., renaming or moving them, also recently there was a case that was apparently caused by the Recycle Bin plugin.

Linking at 6Gbps for me, LSI 9211-4i which is what I had available, so possibly a cable/backplane issue: But like mentioned you're not missing any performance, SATA2 is capable of 275MB/s

Usually yes, as long as no RAID controllers are involved, any VM pass-trough settings might also need tuning if applicable.

BIOS or IPMI, if the board supports it.

That looks like a corrected ECC error, board system event log might have more infi.

Ok, sorry, sometimes I read too fast and miss some parts, you need to do a new config and resync parity, if the old disk14 really went bad you'll lose that data, if that disk still works you can post a SMART report, or if you just want to get the array up and protected do a new config without it.

Any will do but the other end depends on the controller, e.g. sff-8087 is usually used for SAS2 controllers, sff-8643 for SAS3.

Thanks for the update, at first I didn't even consider that could be literally the problem, but it is a good way of protecting the NIC.

Macvlan call traces are usually the result of having dockers with a custom IP address:

With a cable similar to this:

Yes, do a new config without it, parity will need to be synced and the array will not include any data that was on that disk, unless you move it first.

That usually appears in the SMART report, since it doesn't it might be a device problem, but don't really have experience with SAS devices, just by seeing different issues on the forum, one of those is being "formatted with type 2 protection", if you google that you see the solution is to reformat the disks with sg3_utils, you can still try that, if the disks fail to format it most likely confirms a device problem.

It has been known for some time that small file writes to user shares are considerably slow, and they've been getting slower with every new release, anyone dealing with small files should always use disk shares if at all possible, even if you need to reserve just one disk or a pool for that.

It doesn't, as long as cache/pool only has 1 slot set (not just one assigned device).

You're right, I was just looking at the model and didn't check the log, this is the problem: Jan 6 16:06:10 Chaldeas kernel: sd 6:0:0:0: [sdb] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB) Jan 6 16:06:10 Chaldeas kernel: sd 6:0:0:0: [sdb] Write Protect is off Jan 6 16:06:10 Chaldeas kernel: sd 6:0:0:0: [sdb] Mode Sense: f7 00 10 08 Jan 6 16:06:10 Chaldeas kernel: sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA Jan 6 16:06:10 Chaldeas kernel: sd 6:0:0:0: [sdb] Spinning up disk... Jan 6 16:06:10 Chaldeas kernel: .not responding... ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jan 6 16:06:10 Chaldeas kernel: sd 6:0:2:0: [sdd] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 Jan 6 16:06:10 Chaldeas kernel: sd 6:0:1:0: [sdc] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 sdb is correctly initialized, but sdc and sdd fail to read capacity, possibly a disk problem, but they could also have some kind of protection enable, it's common with NetApp drives, though nothing is appearing in the incomplete SMART reports.

Could be either or both, stop overclocking the RAM and make sure the power supply setting is correct.

If the SATA cable doesn't fix it swap power with another disk, parity isn't even given a valid SMART report, it could also be the disk if cables don't help.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Yes, and that's no good, replace the cables, both power and SATA.

Constant ATA errors on these disks: Jan 11 18:26:25 TARDIS kernel: ata3.00: ATA-8: ST2000VN000, W523H9XY, SC60, max UDMA/133 Jan 11 18:26:25 TARDIS kernel: ata4.00: ATA-8: ST31000524AS, 5VPDN8F1, JC4B, max UDMA/133 Check/replace cables and post new diags.

Disk has been failing SMART tests for some time, it should be replaced.

I have one of these, when I have some time I will connect it to an LSI to see if it's a general issue, but not something I would worry about, since SATA2 has enough bandwidth for these disks.