It could also be that it has something to do with mover, which is scheduled to run every two hours.

 

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.

It could also be that it has something to do with mover, which is scheduled to run every two hours.

 

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

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 .

(Small bump )

Just a small comment, in an earlier post you mentioned trying to use xfs_repair on sde.  That can never work and will produce the errors you saw.  It MUST be run on sde1 only.  Repair tools like xfs_repair run on file systems (like sde1, a partition with a file system), not on drives (like sde).

Just a small comment, in an earlier post you mentioned trying to use xfs_repair on sde.  That can never work and will produce the errors you saw.  It MUST be run on sde1 only.  Repair tools like xfs_repair run on file systems (like sde1, a partition with a file system), not on drives (like sde).

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...

Just a small comment, in an earlier post you mentioned trying to use xfs_repair on sde.  That can never work and will produce the errors you saw.  It MUST be run on sde1 only.  Repair tools like xfs_repair run on file systems (like sde1, a partition with a file system), not on drives (like sde).

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.

The wiki says to run it in the md# device, or in special cases, you could run it on the sdx1 partition.

 

The md# device includes parity when making corrections, and in fact, can even be used when the disk is disabled, in which case it would use the emulated disk.

 

Correcting the sdx1 partition would not include parity, so parity would be invalid after the repair.

 

As RobJ says, sdx is not a filesystem, but md# and sdx1 are.

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?

Post the latest diagnostics to check if it's the same error.