Pending Sectors

[CriticalMach]

A few nights ago I had the top of my server off and using an electric blower to clear out dust while the server was on and building hashes for the File Integrity plugin. While doing this I get a notification of 8 pending sectors on 2 separate 8TB shucked reds, disk 1 and 2, in the physical 3 and 4 spots on my supermicro case. I immediately go to the webui and run a quick smart test on both, both pass. I then run an extended smart test on both and they both pass. After that, a non correcting parity sync just finished with zero errors, however both drives still have 8 pending sectors.

 

Shouldn't the parity sync have either had errors when it got to the pending sectors, or if no errors and been able to read them cleared the pending sectors? What logs would anyone need to take a look at this and let me know if they can tell what happened? I've already attached the smart reports for the drives in question. Other than the pending sectors everything else with the drives are working great.

 

Thanks!

WDC_WD80EFZX-68UW8N0_VK1DRDXY-20210523-1237 - Disk 2.txt WDC_WD80EFZX-68UW8N0_VJGMAU6X-20210523-1236 - Disk 1.txt

Edited May 23, 2021 by CriticalMach
formatting

[John_M]

Pending sectors are ones that have failed a read operation and are waiting to be processed (hence, "pending"). Even if subsequent reads are successful, their pending status can only be cleared by a write operation, when the new content is either successfully written to the existing sectors (decrementing the pending sector count) or reallocated to spare sectors (decrementing the pending sector count and incrementing the reallocated sector count). A non-correcting parity check (there's no such thing as a non-correcting parity sync) is, by definition, read-only so there's no opportunity to deal with them there.

 

If Unraid detects a read error it will reconstruct the missing data from parity and the remaining data disks and attempt to write it back to the disk that showed the error. If Unraid detects a write error the offending disk is disabled and its contents emulated, using parity and the remaining data disks.

 

Pending sectors may or may not be readable and that uncertainty is a problem. As mentioned, the ability to emulate disabled disks relies on the ability to read all the remaining disks so it's never a good thing to have a disk with pending sectors in your array. I suspect you disturbed something while cleaning out the dust. If you haven't already rebooted, your diagnostics will shed some light.

 

I think the result of the extended SMART test is reassuring but I would want to replace first one of the disks with a spare and then the other, if only to get rid of the pending sectors. After replacing the first disk I'd run a utility that writes then reads every sector, such as badblocks or preclear, and if the disk turns out to be good, I'd use it as the replacement for the second disk. Then run the same utility on the second disk. A few reallocated sectors is not necessarily a bad thing, as long as the number doesn't keep increasing.

 

[LEKO]

On 5/23/2021 at 4:01 PM, John_M said:

Pending sectors are ones that have failed a read operation and are waiting to be processed (hence, "pending"). Even if subsequent reads are successful, their pending status can only be cleared by a write operation, when the new content is either successfully written to the existing sectors (decrementing the pending sector count) or reallocated to spare sectors (decrementing the pending sector count and incrementing the reallocated sector count). A non-correcting parity check (there's no such thing as a non-correcting parity sync) is, by definition, read-only so there's no opportunity to deal with them there.

 

If Unraid detects a read error it will reconstruct the missing data from parity and the remaining data disks and attempt to write it back to the disk that showed the error. If Unraid detects a write error the offending disk is disabled and its contents emulated, using parity and the remaining data disks.

 

Pending sectors may or may not be readable and that uncertainty is a problem. As mentioned, the ability to emulate disabled disks relies on the ability to read all the remaining disks so it's never a good thing to have a disk with pending sectors in your array. I suspect you disturbed something while cleaning out the dust. If you haven't already rebooted, your diagnostics will shed some light.

 

I think the result of the extended SMART test is reassuring but I would want to replace first one of the disks with a spare and then the other, if only to get rid of the pending sectors. After replacing the first disk I'd run a utility that writes then reads every sector, such as badblocks or preclear, and if the disk turns out to be good, I'd use it as the replacement for the second disk. Then run the same utility on the second disk. A few reallocated sectors is not necessarily a bad thing, as long as the number doesn't keep increasing.

 

I stumble upon this thread, because my parity drive now have Current pending sector count of 2 and I could not find any meaningful information about this particular S.M.A.R.T. metric.

Based on your post @John_M, it would be nice to have a nice S.M.A.R.T. counters reference document/post with any tips on how to fix our workaround those errors.

Based on what you said, I'll run GRC's SpinRite on Level2 on my parity drive to force a read/write and hopefully clear this pending sector counter. Oddly enough, my parity drive is one of the newest drive of my array. My other drive reports 1 uncorrected error, I'll probably also try to do a pass with SpinRite to ensure there is no other underlying problem.

 

tower-smart-20211029-0736.zip tower-smart-20211029-0734.zip

[johnzimm]

On 10/29/2021 at 7:46 AM, LEKO said:

 I'll run GRC's SpinRite on Level2 on my parity drive to force a read/write and hopefully clear this pending sector counter.

Di you have any luck running Spinrite on the disk?