Can you force sectors to remap on a parity disk?

KYThrill · February 7, 2011

This weekend was not a good weekend for my unRAID. My Hitachi parity drive started throwing read errors, 215 to be exactly. SMART still lists the health status as good, but looking at the SMART data, the Reallocated Sectors Count is 7 and the Current Pending Sector Count is 7. Uncorrectable Sector Count is 0.

I did a parity verify and aside from a bunch of read errors, it passed. All errors point to the same LBA, every time I check it. SMART reports 30 errors in the history, but the past five are all identical, all at the same LBA (before and after a parity verify).

Is there a way to get rid of these read errors? The pending sectors will not remap until written to, and who knows how long that might be. But I'll continue getting read errors until it does.

I ran the Hitachi DFT tool and according to it, the drive is good and I can't RMA it until the DFT tool reports an error code, so I'm forced to use it for something. 7 reallocated sectors isn't too bad I guess, but I still don't like it. Fortunately I have two pre-cleared Hitachi drives in backup, so I just popped one in and rebuilt parity and I'm all green now.

But what to do with this drive? Can I still trust it enough to put it back in my pool of spare parity drives? Is it worth it to use it as my next data drive? I guess pre-clearing it should force it to remap the pending sectors (which will take reallocated sectors up to 14)? Since I can't RMA it yet, I feel like I should be using it until it is failed enough to get the RMA. The drive is only 5 months old, so it's a waste if I can't use it or get it RMA'd.

What's everyone's thoughts?

Joe L. · February 7, 2011

As you said, running the preclear script on it should re-allocate the sectors. If it is just the few sectors you'll know soon enough.

Make sure you use the most recent preclear script. (It is version 1.4 as if this post)

check the version with

preclear_disk.sh -v

Joe L.

SSD · February 7, 2011

They should remap themselves during a parity check. Will be interested to see if preclearing remap sectors that the parity check does not.

Joe L. · February 7, 2011

They should remap themselves during a parity check. Will be interested to see if preclearing remap sectors that the parity check does not.

No, a parity check is a read operation. There is no why for unRAID to know what to save in the sector until it is written.

You could set a new disk configuration and force a write of parity with what should be an identical copy of itself.

Joe L.

SSD · February 8, 2011

They should remap themselves during a parity check. Will be interested to see if preclearing remap sectors that the parity check does not.

No, a parity check is a read operation. There is no why for unRAID to know what to save in the sector until it is written.

You could set a new disk configuration and force a write of parity with what should be an identical copy of itself.

Joe L.

There are 2 situations - either there is a read error on the parity disk, or there is not a read error on the parity disk.

1. If there is a read error, unRAID will reconstruct the parity sector and rewrite it to the disk. This will force a remap.

2. If there is NOT a read error, yet the smart system detects a failing sector, it will invisibly remap the sector.

This is my understanding of how the smart system is supposed to operate.

Either way, the parity check should eventually remap a bad or marginal sector.

Joe L. · February 8, 2011

There are 2 situations - either there is a read error on the parity disk, or there is not a read error on the parity disk.

1. If there is a read error, unRAID will reconstruct the parity sector and rewrite it to the disk. This will force a remap.

2. If there is NOT a read error, yet the smart system detects a failing sector, it will invisibly remap the sector.

This is my understanding of how the smart system is supposed to operate.

Either way, the parity check should eventually remap a bad or marginal sector.

I've seen "smartctl" reports of sectors pending re-allocation on both the parity and data drives.

My suspicion is that those fall into your "#2" category of being detected by the SMART firmware on the disk. I also suspect they may have been detected during the normal "read-ahead" of sectors on a disk, so no error is returned to the OS, since the sector with the error was not being requested.

Joe L.

KYThrill · February 8, 2011

Well, running the Advanced Test on the Hitachi DFT tool did make the sectors remap. I guess it must read and write as part of whatever test it does. So the drive now stands at 14 reallocated sectors, 0 pending and the DFT still still says the drive is green and not eligible for an RMA.

So my dilemma is whether to shelve it and use it as a spare parity drive, rebuild parity on it and remove my current spare with 0 bad sectors (hate to rebuild since I just did it two days ago), or insert it as a data disk back into my array, use it and see if it continues to develop bad sectors.

My warranty is good until 2013, so I guess I have some time to get some use out of it.

I'm currently pre-clearing it, so we will see if that results in anymore reallocated sectors. The first time I precleared it (when it was new), it took 30 hours. I started last night at 10 pm and this morning at 9 am, it was 60% through Part 2, showing a 120 MB/s write speed. So it seems to be on track.

I wish I knew how many reallocated sectors it would need to see for Hitachi to consider it failed.

Joe L. · February 8, 2011

I wish I knew how many reallocated sectors it would need to see for Hitachi to consider it failed.

Most large disks have a reserve pool of several thousand sectors. I don't know of any manufacturer that tells their threshold.

Just keep an eye on it.

Joe L.

KYThrill · February 9, 2011

I wish I knew how many reallocated sectors it would need to see for Hitachi to consider it failed.

Most large disks have a reserve pool of several thousand sectors. I don't know of any manufacturer that tells their threshold.

Just keep an eye on it.

Joe L.

Okay, there may be a problem with the drive pre-clearing.

The drive went through Step 1 to Step 10 and each step says done. However, doing a post read, it appears to have hung at 12%. It hasn't moved from 12% in hours and my syslog just keeps repeating the following:

Feb 8 13:08:49 Tower kernel: Descriptor sense data with sense descriptors (in hex):

Feb 8 13:08:49 Tower kernel: 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00

Feb 8 13:08:49 Tower kernel: 00 00 00 27

Feb 8 13:08:49 Tower kernel: sd 0:0:0:0: [sdb] ASC=0x0 ASCQ=0x0 (Drive related)

Feb 8 13:08:49 Tower kernel: sd 0:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 ab 1f 2b 28 00 00 08 00 (Drive related)

Feb 8 13:08:49 Tower kernel: end_request: I/O error, dev sdb, sector 2870946600 (Errors)

Feb 8 13:08:49 Tower kernel: ata1: translated ATA stat/err 0x51/04 to SCSI SK/ASC/ASCQ 0xb/00/00 (Drive related)

Feb 8 13:08:49 Tower kernel: ata1: status=0x51 { DriveReady SeekComplete Error } (Errors)

Feb 8 13:08:49 Tower kernel: ata1: error=0x04 { DriveStatusError } (Errors)