Hello,
I had a unexpected shutdown a couple days ago:

Jan  2 18:20:46 Tower root: Fix Common Problems: Error: unclean shutdown detected of your server

I started a parity check this morning and it resulted in 768 errors.  Looking in the log:

Jan  4 17:09:46 Tower kernel: md: recovery thread: P corrected, sector=5087241624
Jan  4 17:09:46 Tower kernel: md: recovery thread: P corrected, sector=5087241632
Jan  4 17:09:46 Tower kernel: md: recovery thread: P corrected, sector=5087241640
Jan  4 17:09:46 Tower kernel: md: recovery thread: P corrected, sector=5087241648

These same errors continue in what seem to be sequential sectors.

The array seems to be working fine.  Is this anything to be concerned about before I move on with my plan of shrinking the array by removing an HDD and replacing it with an SSD for a cache drive?

 

Thanks for any help!

 

Perfectly normal to have a few sync errors after an unclean shutdown, just make sure they were corrected.

The corrections happens because the operating system buffers writes. And a change to a file or file system means that writes needs to be sent to both data disks and parity disk(s). After an unclean shutdown, some writes may have managed to hit the party drive but not the data drive. Or maybe the data drive got some written data a bit earlier than the parity drive.

 

It's impossible for a software solution to keep a multi-disk write synchronized if you get a hang, power-loss etc.

 

That's why enterprise level servers uses dedicated hardware RAID with a RAID-controller that has a battery backup. So the OS sends down the data to write to the RAID controller. Then it emits a "commit" to confirm that a complete write have been sent. If the OS then locks up or the power is lost, it doesn't matter if the individual disks have had time to process the data - the RAID card will synchronize the disks with the pending writes when powered up the next time. Or if the power was lost in the middle of the transaction, then the partial data is thrown away without any of the disks seeing it.

So - there are some advantages with an enterprise-level RAID. And quite a number of disadvantages, besides the cost. unRAID tries to get around all the disadvantages.

2 hours ago, pwm said:

After an unclean shutdown, some writes may have managed to hit the party drive but not the data drive.

In theory, that should never happen, the data drive writes have priority. In practice, I don't think I've ever seen a report of an unclean shutdown where the data drive was corrupted but using the emulated parity information was correct.

 

That, plus the fact that parity mismatch can't be pinned to a specific drive, is why a correcting parity check only modifies the parity, never the data drives.

 

12 minutes ago, jonathanm said:

In theory, that should never happen, the data drive writes have priority. In practice, I don't think I've ever seen a report of an unclean shutdown where the data drive was corrupted but using the emulated parity information was correct.

Even when a data drive is given priority, it's easy to go wrong with the write caching layers. Even single-drive file system logic has a hard time to get the write barriers to manage all corner cases correctly as can be seen if reviewing the history of the Linux kernel and the different file system implementations.

 

14 minutes ago, jonathanm said:

That, plus the fact that parity mismatch can't be pinned to a specific drive, is why a correcting parity check only modifies the parity, never the data drives.

 

The really important reason why parity mismatch must be solved by rewriting the parity and never try the reverse direction even if the system knows only one data drive could have been receiving writes before the failure, is that sending the fixes to the data drive would invalidate the journaling support of the file system.

 

Thanks for the info!