Ziggy

Recreating the Docker image did indeed seem to have resolved the issue. Unfortunately I cannot share the statusfile since I reinstalled the plugin to see if that would fix the permissions:(. I'll look into why the cache drive was acting up, I agree that this was probably a coincidence and has nothing to do with RP. Cheers!

For some reason, since the last update, my shares all got locked after I tried accessing one of them through AFP. After making sure it was safe to do so, I clicked the lock to remove the set permissions. Unfortunately though, all of my shares and drives are still locked as the evidence shows here: https://gyazo.com/8ace667bfe6d256249e39375f82ec8ea . All of my docker containers are down, the interface is pretty slow, Unraid is unusable. I tried manually locking and unlocking again, but no joy. Please assist. Diagnostics attached. Many thanks in advance. EDIT: FCP is reporting the following: https://gyazo.com/0ea8b65802771e412bc3cd30bf200cde . The cache consists of two RAID0 BTRFS devices and is most definitely not full: https://gyazo.com/8c71225e2b0c5105552bfc2a90ca491b . EDIT2: it looks like I am able to write on every disk, except for the cache. EDIT3: after running the mover, I'm able to write again. It might be a big coincidence that this occurred after everything got locked down. Unraid is reporting plenty of space left though, so I'm not sure why this is not the case... ziggy_unraid-diagnostics-20161107-1954.zip

The issue still persists with the 1430sa, which is annoying since I've thrown in quite some money while still being at square one... I think the issue occurs when parity check and mover collide, causing the mover to keep running indefinitely and parity check to drop to extreme low speeds. At this point, I have replaced pretty much all of the relevant hardware (MB, Disks, controller, CPU, RAM, NIC) with still no clue what so ever as to what is causing this bizarre behavior... Is there a way to prevent mover from running during parity checks?

Interesting, thanks for pointing that out. I honestly can't remember whether I actually ran it on the disk itself or not, but the corruptions error were in fact resolved so I'm assuming I did in the end. If I recall correctly, that's what the wiki says as well. Quick update: I ordered an Adaptec 1430sa on Ebay. It did cost me about 50USD for shipping and import, but since I couldn't fine an alternative...

(Small bump )

Tried with a Highpoint Rocket 640L (which uses the same marvell chip though) since I couldn't find a good deal for the on you recommended (I'm based in Belgium). Same result. Issue still appears with mover disabled, and during manual parity check (it was one hell of a coincidence before, I apologise for sharing a faulty/assumed explanation). I would really, really appreciate some help picking out a controller that is available to me. Here's a list with a SATA 4port filter, is there anything on there you would recommend? https://www.alternate.be/html/product/listing.html?navId=1398&lk=8969&showFilter=false&hideFilter=false&disableFilter=false&filter_-1=1700&filter_-1=78900&filter_2125=4.0#listingResult .

Not really a good idea to have the mover running during a parity check, it will slow down both things considerably, though it won't cause any errors on a stable server. I'll try replicating with mover disabled

I'm just not inclined to believe that after 3 attempts, having randomly run between 1 and 3 manual parity checks before setting up a scheduled check, this is just a coincidence. First time, sure. Second time, ehe why not? But three times in a row, being able to reproduce it like that...? I don't know what to tell you. It could also be that it has something to do with mover, which is scheduled to run every two hours.

Replaced motherboard with the exact same model, ran two MANUAL parity checks: no problems. Ran a scheduled parity check: problem (see logs). I have been able to reproduce this three times now, it seems like only the scheduled parity check triggers this behaviour... Any more advice? ziggy_unraid-diagnostics-20160915-1843.zip

**sigh** Happened again, after 5 days of uninterrupted usage, coincidentally in the time-frame when the automated parity check was supposed to run. Seems to be the drives attached to that SATA controller again (see logs). I'm going to replace the board once more.

Okay, I simply reconstructed the disk by starting the array without the parity disk prior to re-adding it. I was under the impression that this would format the drive since I did not realize the parity disk does not have a FS. So I guess it just overwrote the disk. In any case, my box is still up and running after 3 days. I really thought it was a hardware issue and am bummed we'll probably never know what it was.

Not really, did you grab the diagnostics when that happened? Same behavior as originally described in this post. PCIe disks going offline during a parity check, formatting the parity disk **seems** to have resolved the issue... Exact same hardware, only an upgrade to Unraid 6.2

I'm puzzled. I noticed that some of the disks in the array only went into error mode during a parity check. So I wiped the parity and rebuilt it, and after 48+ hours, the issues seem to have gone away... Is it possible that a corrupt parity caused the parity check algorithm to crash?

Hmm, upgrading to v6.2-rc4 did not resolve the issue. How would you recommend I go about moving the data to a new disk? Can I MV everything or should I use specialized tools?

Bump, still experiencing this issue All my user shares disappeared and I'm getting this error when executing 'ls' in /mnt/user/: https://gyazo.com/2bd24cb0091d09ef165932e6f6cf74ac