Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

SMART is stating one pending sector on of my server's hdd. I've read lot's of articles recommending using hdparm to "easily" force the disk to relocated the bad sector, but I can't find the correct way to use it.

Some info from my "smartctl":

Error 95 occurred at disk power-on lifetime: 20184 hours (841 days + 0 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 d7 55 dd 02  Error: UNC at LBA = 0x02dd55d7 = 48059863

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  c8 00 08 d6 55 dd e2 00  18d+05:13:42.421  READ DMA
  27 00 00 00 00 00 e0 00  18d+05:13:42.392  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 02  18d+05:13:42.378  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 02  18d+05:13:42.355  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00  18d+05:13:42.327  READ NATIVE MAX ADDRESS EXT

 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%     20194         48059863
 # 2  Short offline       Completed without error       00%     15161         -

With that "bad LBA" (48059863) in hand, how do I use hdparm? What type of address the parameters "--read-sector" and "--write-sector" should have?

If I issue the command hdparm --read-sector 48095863 /dev/sda it reads and dumps data. If this command was right, I should expect an I/O error, right?

Instead, it dumps data:

$ ./hdparm --read-sector 48059863 /dev/sda

/dev/sda:
reading sector 48059863: succeeded
4b50 5d1b 7563 a932 618d 1f81 4514 2343
8a16 3342 5e36 2591 3b4e 762a 4dd7 037f
6a32 6996 816f 573f eee1 bc24 eed4 206e
(...)
share|improve this question
1  
The proper thing to do is to send the drive back to its manufacturer and get a warranty replacement. –  Michael Hampton Dec 27 '12 at 16:58

3 Answers 3

Based on this answer and this answer in How do I easily repair a single unreadable block on a Linux disk?, you want to use hdparm to write to the sector. Assuming /dev/hda is your device and 48059863 is the LBA of the sector:

hdparm --write-sector 48059863 /dev/sda

That will blow away whatever data is in that sector. You'll need to add '–yes-i-know-what-i-am-doing' to get it to actually write. Note the dire warning before proceeding.

According to the second answer I linked, the drive will recover the sector if it can and remap it (if there is enough ECC correct the problem). If it can't get a good read on the data, it won't, since it doesn't know what to write and won't write garbage data. You're getting a successful read with --read-data, so I'd think the drive would eventually remap the sector on it's own if there is really a problem. Maybe it was a one time glitch and the sector is actually fine?

share|improve this answer
    
So that's the strange part and the reason of my question. If I issue a test with smartctl it will stop at LBA 48059863, and right after, If I issue the hdperm using the same LBA address it will read the sector with no errors. We are missing something here, it does not seem to be a temporary problem. –  Nino Dec 27 '12 at 21:12
    
It's strange that this iterative process (of looking for the next bad sector through SMART and forcing it to re-allocate) isn't automated with a simple utility!.. –  imz -- Ivan Zakharyaschev Dec 10 '13 at 19:06

If for whatever reason you prefer to try to clear those bad sectors, and you do not care about the existing contents of a drive, the below shell snippet may help. I tested this on an older Seagate Barracuda drive that is well past its warranty anyway. It might not work right with other drive models or manufacturers, but it should put you on the right path if you must script something. It will destroy any content you have on the drive.

You may prefer just running badblocks, an hdparm Secure Erase (SE) (https://wiki.archlinux.org/index.php/Securely_wipe_disk), or some other tool that is actually designed for this. Or even the manufacturer provided tools like SeaTools (there is a 32bit linux 'enterprise' version, google it).

Make sure the drive in question is completely unused/unmounted before doing this. Also, I know, while loop, no excuses. It is a hack, you can make it better...

baddrive=/dev/sdb
badsect=1
while true; do
  echo Testing from LBA $badsect
  smartctl -t select,${badsect}-max ${baddrive} 2>&1 >> /dev/null

  echo "Waiting for test to stop (each dot is 5 sec)"
  while [ "$(smartctl -l xselftest /dev/sdb | awk '/# 1  Selective offline/ {print $5}')" != "Completed:" ]; do
    echo -n .
    sleep 5
  done
  echo

  badsect=$(smartctl -l xselftest $baddrive | awk '/# 1  Selective offline   Completed: read failure/ {print $10}')
  [ $badsect = "-" ] && exit 0

  echo Attempting to fix sector $badsect on $baddrive
  hdparm --repair-sector ${badsect} --yes-i-know-what-i-am-doing $baddrive
  echo Continuning test
done

One advantage of using the 'selftest' method is the load is handled by the drive firmware, so the PC it is connected to is not loaded down like it would be with dd or badblocks.

share|improve this answer

I think it may have read without error because that sector is not bad, but other tools fail reading the sector because of some other behavior. (read ahead that reaches an actually unreadable sector?)

I found some bad sectors, and if I repair the only one that is unreadable with "hdparm --read-sector", the other 'bad' sectors suddenly are no longer unreadable with things like dd. And interestingly, when looking at "dmesg" output, only the hdparm-unreadable ones are ever reported.

eg. I had sectors 36589320 to 36589327, and 36589344 to 36589351 unreadable with dd, but only 36589326 and 36589345 were unreadable with hdparm --read-sector. Then I used hdparm --write-sector on those 2, and then all 16 sectors were readable again.

Here's a small part of dmesg output:

[30152036.527940] end_request: I/O error, dev sda, sector 36589326
[30152077.363710] end_request: I/O error, dev sda, sector 36589345

And the disk info:

# smartctl -i /dev/sda
...
=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA MK2002TSKB
...
Firmware Version: MT2A
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Size:      512 bytes logical/physical
...

And apparently this disk's firmware either doesn't properly record reallocated sectors, or they weren't really reallocated, but just corrupt (like an unrecoverable ECC error, but the surface still works, like it was caused by bit rot rather than faulty electronics or bad media):

# smartctl -A /dev/sda | egrep "Reallocated|Pending|Uncorrectable"
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0

# smartctl -l error /dev/sda
...
SMART Error Log Version: 1
No Errors Logged

Please note, I ran a --read-sector and a --write-sector. A read may be required to properly reallocate a sector, not just a write. If you don't read first, it might not know the sector is bad.

share|improve this answer
    
Yes, you're right. This is because the kernel reads "pages" not sectors. A page is 4096 bytes = 8 sectors. They are aligned to boundaries (4096-byte) as well. –  dmansfield Sep 3 at 21:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.