Jump to content

Slow Parity Check after Unclean Shutdown


Hoopster

Recommended Posts

I was running a parity check when power to the house was lost in a violent storm (started check before storm rolled in).  I have a UPS and it was configured, but, for some reason it did not kick in.  When the storm quit and I brought my server back up, of course, it detected an unclean shutdown and started a parity check.  The first parity check was running at about 140 MB/sec.  This second parity check is running at about 40 MB/sec.  Why the big difference?

 

 

EDIT:  Of course, two minutes after I post this, parity speed jumped up to ~144 MB/Sec after running for 40 minutes at 40 MB/sec or less.

syslog.zip

Link to comment

Nothing in your syslog, but part of the problem could be when the system boots back up and automatically starts a check, you've also got cache_dirs scanning all your folders initially, any dockers that scan for media (plex, couch, sonarr, etc) all doing it at the same time.  If this is all happening, then I'm not surprised about the speed.

Link to comment

Nothing in your syslog, but part of the problem could be when the system boots back up and automatically starts a check, you've also got cache_dirs scanning all your folders initially, any dockers that scan for media (plex, couch, sonarr, etc) all doing it at the same time.  If this is all happening, then I'm not surprised about the speed.

 

Well, since speed jumped back up to where it was, you are probably correct about cache_dirs, etc.  It has been a while since I rebooted the server and I am not usually doing a parity check on boot, so I forgot about those other things.  :)

 

Thank you.

Link to comment

To add to the comments above, a parity check after a bad shutdown tends to run much slower for awhile, because the drives have to mount and the file system on some drives have to be repaired.  If they are formatted with ReiserFS, then you will see 'replayed # transactions' for one or more drives, in the syslog.  I'm not sure what the newer file systems say.  And because the parity check is running, the repairs take much longer, they are each slowing the other down.  Once the last drive and file system is mounted successfully, and all other scanning operations are complete, then the parity check will return to full speed.  Unless of course the storm caused an electrical spike sufficiently strong to scramble sector data!  Then there may be delays while a drive tries to test and repair sectors.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...