JorgeB

Parity doesn't mount since there's no filesystem, also don't try to mount any of the data disks, except in read only mode, I'll post the instructions for the invalid slot command in a few minutes.

Yep, and please report back if it works.

Oct 9 21:33:06 Tower dhcpcd[2621]: eth0: soliciting a DHCP lease Oct 9 21:33:06 Tower dhcpcd[2621]: eth0: offered 10.0.0.251 from 10.0.0.1 Oct 9 21:33:06 Tower dhcpcd[2621]: eth0: probing address 10.0.0.251/24 Oct 9 21:33:10 Tower dhcpcd[2621]: eth0: leased 10.0.0.251 for 86400 seconds It appears to be working correctly, did you try accessing the server using the IP address?

Those are likely harmless and possibly related to APM, IIRC one could get rid of them by changing the APM level, just don't remember if it was minimum or max that worked, change one of the disks to minimum and another to max: hdparm -B 1 /dev/sdX hdparm -B 254 /dev/sdX See if it has any effect, note that settings will revert after a reboot.

It's very possible, like mentioned most likely connection or power problem, firmware might or not have an impact, but good to upgrade if possible.

Your missed the trailing slash, look for a disk4 folder on disk3.

Try disabling WSD (Settings -> SMB)

Adding a new cache device by default results in a raid1 pool, it won't increase available space, also not a good idea to add a device with a full filesystem, besides the device you added dropped offline (check cables), but first you need to free up some space on cache, move or delete some data.

Backup the key from the flash drive, re-create it using the USB tool, restore the key.

Problems with multiple devices: Oct 2 09:35:46 Tower kernel: sd 9:0:5:0: Power-on or device reset occurred Oct 2 09:35:46 Tower kernel: sd 9:0:7:0: Power-on or device reset occurred Oct 2 09:35:46 Tower kernel: sd 9:0:1:0: Power-on or device reset occurred Oct 2 09:35:46 Tower kernel: sd 9:0:2:0: Power-on or device reset occurred Oct 2 09:35:46 Tower kernel: sd 9:0:4:0: Power-on or device reset occurred This usually suggests a connection/power problem. Also make sure to update the LSI firmware: mpt2sas_cm0: LSISAS2308: FWVersion(20.00.06.00) All p20 releases except 20.00.07.00 have known issues

Rebuilding the disk on top would re-partition it, IIRC he already did that before doing the new config, but didn't finish the rebuild.

Try booting in safe mode with all services disable, if no errors after a couple of days start turning them on one by one.

I honestely don't know, never did much testing on that, time permitting I'll try doing some over the weekend, with different workloads and a couple of controllers, to see if there's any clear difference one way or the other.

Possibly, maybe better to leave it disabled for now, I will since I don't see any performance advantage.

Sorry missed this part earlier, no, that wasn't the problem, since the checksum error would always be logged in the syslog, and if I tried to copy the file locally I would always get an i/o error, with SMB (and aio read enable) it would still copy successfully despite the checksum error. BTW, just did a test on beta30, with aio enable, and it's behaving correctly, i.e., a file with just a single sector corrupt will fail to copy, tried 20 times, and always got this: At the same time a checksum error is logged (before only this part happened): So that issue appears to be fixed.

Yep, two SASLP, you should difinetely get rid of those, it's not clear the disk is OK, you need to reboot an post ne diags, but still they can cause more trouble when there are errors because the driver crashes. Also make sure scheduled parity checks are set to non correct.

IIRC I used dd to write some zeros on existing data, the larger the write (corruption), the more likely it would cause an i/o error during an SMB transfer, a single corrupt sector would always (or almost always) go through.

In one of my main servers I have both aio read and write set to 0, on another just read, never noticed any issue with writes, but didn't do much testing, my original issue was btrfs ignoring cheksum errors on reads, performance was similar when I tested at the time.

I believe so.

It's logged as a disk problem, you should

I remember this also caused an issue with btrfs failing to give an i/o error if data corruption was found, I still have those entries in my Samba extra settings to disable aio.

Yep, get one of the recommended LSI HBAs.

Difficult to guess without the diags, next time it happens grab them before rebooting.

Preclear script has nothing to do with the array, like mentioned Unraid requires all assigned devices to have a unique identification, maybe that string can be changed in the controller, you can also try toggling Setings -> Display Settings -> Display world-wide-name in device ID

I usually buy Supermicro.