Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Extremely slow parity sync after loss of power

Featured Replies

I'm running 4.4.2 on a 6 disk array.  I accidentally knocked the power cable off of system and effectively shut off the box uncleanly.  After booting it back up, parity disk is has a red mark.  Another reboot brought it to blue status and started a parity sync.  Everything's back to normal I thought, until I saw the speed of the parity sync.  793 KB/sec.  So I ran some smart reports on the drives but I couldn't make heads of tails of it.  As far as I can tell, everything looks normal.  Any suggestions?

 

I notice the smart report took a lot longer to return when I ran it on the parity drive.  All other drives ran the report within seconds.

 

Attached are syslogs and smart reports.  I had to zip the syslog since it was over 128kb

  • Author

more smart reports.

I have never seen behavior quite like this before, so I can't answer very confidently here.  The parity drive is the only component having problems, but it is really handicapping you at the moment.  Its SMART report looks very good, with only 150 power-on hours and no remapped or pending sectors, but it does indicate 12 Reported_Uncorrect sectors, which corresponds to the ATA Error Count of 12, at least the last 5 of which occurred at 150 power-on hours, and also correspond to the media errors in very early sectors, reported in your syslog before the drive setup had even finished.  Once setup finished and the array was started, then a parity sync begins, but immediately, major communications problems are reported with the parity drive.  No media errors are reported, but the exceptions are *very* consistent, almost always returning the 'PHYRdyChg LinkSeq TrStaTrns' SATA error flags, occasionally adding the 'Dispar' flag, often with "ata1.00: hot unplug" messages, plus numerous time-consuming resets.  It never has a problem with the SATA link at 3.0, but decides to slow the mode down to UDMA/33, but no improvement.

 

This does not make sense to me.  It appears like a communications problem, but there is no randomness or inconsistency, so I don't think a cable replacement will help.  One possibility is that the drive is so busy analyzing the sector problems, that it is too busy to respond to normal drive requests, but I can't imagine a busy drive returning 'hot unplug' messages and communications flags like the above.  If nothing else, it should just time out, stop responding at all.  The drive itself seems confused, trying to deal with these possibly bad sectors, but so far has not remapped or even classified any of them as 'Pending'.  It is possible that an electrical issue at the moment of the power cut may have affected it.

 

I think I would un-assign the drive and thoroughly test it, with a SMART long test and/or a couple of Preclear runs.  At the moment, it does not appear usable as a parity drive.

  • Author

Thank you Rob for the suggestions, I will unassign it and run long smart test and preclear runs.  I did notice after posting that the parity drive is making constant start-up whine noise.  It sounds as if the motor is spinning up from a dead stop(perhaps it's a slow down noise?), but the sound only last maybe 1/4 of second and it does that every 15 seconds or so?

 

This is a brand new drive, 7200.12 that is half height of a normal drive.  I'm starting to be really disappointed with Seagate drives.  This will be my 3rd RMA.  When they come back as recertified, I don't really know if I can trust it.

Did it sound like that before the power was cut to it?  That is not a good sign.  The next SMART test should report something.

  • Author

The noise started after the power cut.  :(

 

I tried to run a long test by issuing smartctl -d ata -tlong /dev/sde > /boot/p.120409.txt

 

It says Testing has begun, Please wait 96 min for test to complete.

User smartctl -X to abort test.

 

After 2 hours, still nothing in the file, so I just ctrl+C out of it.  I didn't want to leave the drive on all night.  Not sure what was going on.

 

Here's the latest short smart report and syslog.

I think you've managed to lose the disk.  I'd get a replacement on the way as quickly as possible.  You're running with unprotected data right now and another outage could take out another.

  • Author

I think you've managed to lose the disk.  I'd get a replacement on the way as quickly as possible.  You're running with unprotected data right now and another outage could take out another.

 

That's where I'm headed too, the drive seems hopeless now.  BTW, at the time of the power loss, it was in the middle of writing a file, do I or can I run a fsck on the drive to make sure everyting's ok?

 

 

I think you've managed to lose the disk.  I'd get a replacement on the way as quickly as possible.  You're running with unprotected data right now and another outage could take out another.

 

That's where I'm headed too, the drive seems hopeless now.  BTW, at the time of the power loss, it was in the middle of writing a file, do I or can I run a fsck on the drive to make sure everyting's ok?

 

 

There is NO file system on a parity disk, therefore, no "fsck" can help or find anything.

 

The only diagnostic is the SMART long or short reports.

 

When you request a "long"  SMART report you should disable the spin-down of your drieves, otherwise, it will terminate the test when forced to spin down. 

 

The command you used to "request" a "long" report only starts it running.  It returns almost immediately once the request is acted upon.  The actual results of the "long" test are gotten by running a smart status report AFTER waiting the appropriate amount of time. (a few hours)

 

So,

1. Disable drive spin-down

2. Request a long SMART test of the parity drive

3. Wait the appropriate time

4. Request a SMART status report to see how the "long" test did.  (If it is still running it will say so)

Joe L.

  • Author

The prompt didn't return when I ran it, probably due to the unnecessary redirect I put in there.  I'll try the steps you outlined, I am still curious what happened to the drive.

 

As for fsck, I wanted to run it on the data drive, drive 3 to be exact, since it was being written to at the time.

 

I think you've managed to lose the disk.  I'd get a replacement on the way as quickly as possible.  You're running with unprotected data right now and another outage could take out another.

 

That's where I'm headed too, the drive seems hopeless now.  BTW, at the time of the power loss, it was in the middle of writing a file, do I or can I run a fsck on the drive to make sure everyting's ok?

 

 

There is NO file system on a parity disk, therefore, no "fsck" can help or find anything.

 

The only diagnostic is the SMART long or short reports.

 

When you request a "long"  SMART report you should disable the spin-down of your drieves, otherwise, it will terminate the test when forced to spin down.   

 

The command you used to "request" a "long" report only starts it running.  It returns almost immediately once the request is acted upon.  The actual results of the "long" test are gotten by running a smart status report AFTER waiting the appropriate amount of time. (a few hours)

 

So,

1. Disable drive spin-down

2. Request a long SMART test of the parity drive

3. Wait the appropriate time

4. Request a SMART status report to see how the "long" test did.  (If it is still running it will say so)

Joe L.

  • Author

is the test complete?  I ran smartctl -a -d ata /dev/sda > /boot/p.120509.txt after 96 min that it recommended.

is the test complete?  I ran smartctl -a -d ata /dev/sda > /boot/p.120509.txt after 96 min that it recommended.

Yes, both of the recent "long" tests were run, and both failed with "read failures" at the 90% point.

 

SMART Self-test log structure revision number 1

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Extended offline    Completed: read failure      90%      153        59688

# 2  Extended offline    Completed: read failure      90%      150        8494

# 3  Extended offline    Completed without error      00%        4        -

 

The SMART report show the drive has been powered on for 155 hours, so the two long tests that failed were the ones you recently requested.

  9 Power_On_Hours          0x0032  100  100  000    Old_age  Always      -      155

  • Author

I guess the report tells the story.  Thank you for the help on this.  It's surprising how expensive a power cut can be.

I guess the report tells the story.  Thank you for the help on this.  It's surprising how expensive a power cut can be.

A UPS is a nice addition.  ;) ;)
  • Author

I guess the report tells the story.  Thank you for the help on this.  It's surprising how expensive a power cut can be.

A UPS is a nice addition.  ;) ;)

 

It only works if you don't pull the plug right out of the power supply while the UPS watches in horror.  :)

I guess the report tells the story.  Thank you for the help on this.  It's surprising how expensive a power cut can be.

A UPS is a nice addition.  ;) ;)

 

It only works if you don't pull the plug right out of the power supply while the UPS watches in horror.  :)

Oops...  sorry I said anything to bring back such sad memories... :-[
  • Author

This is just strange.  I took out the parity drive and replaced it with a new drive.  Then the failed parity drive was put into an external HD enclosure, it worked just fine.  No noises, no slowness.  It copied a 12.3Gb file in under 9 min. that's 23MB/s not bad at all.

  • Author

But it fails short self drive test using seatools.  Time for RMA.

Archived

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

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.