Samsung drive reports to high relocated sector count

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Samsung drive reports to high relocated sector count

Martin Steigerwald

Hi!

My external samsung drive reports to high relocated sector count. I have
plugged it to an IBM ThinkPat T42 via Delock PCMCIA eSATA adapter which
is a Silicon Image:

shambhala:~> lspci -nn | grep -i Sil
03:00.0 Mass storage controller [0180]: Silicon Image, Inc. SiI 3512
[SATALink/SATARaid] Serial ATA Controller [1095:3512] (rev 01)

The drive is hosted in a Delock 2.5 inch USB/eSATA harddisk case.

I now suspect the problems arose from my fault of not connecting the USB
power cable properly. It has to USB connectors and instead of the primary
one I connected the secondary one intended to USB hubs that provide too
less power on one port. My T42 provides enough power tough.

Anyway my ThinkPad lost the drive during activity several times like this:

Apr 10 20:43:35 localhost kernel: EXT4 FS on dm-0, internal journal on
dm-0:8
Apr 10 20:43:35 localhost kernel: EXT4-fs: delayed allocation enabled
Apr 10 20:43:35 localhost kernel: EXT4-fs: file extents enabled
Apr 10 20:43:35 localhost kernel: EXT4-fs: mballoc enabled
Apr 10 20:43:35 localhost kernel: EXT4-fs: mounted filesystem with ordered
data mode.
Apr 10 20:44:10 localhost kernel: JBD: barrier-based sync failed on
dm-0:8 - disabling barriers
[...]
Apr 10 20:47:56 localhost kernel: ata8.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x0
Apr 10 20:47:56 localhost kernel: ata8.00: BMDMA2 stat 0x50001
Apr 10 20:47:56 localhost kernel: ata8.00: cmd
35/00:38:28:6a:56/00:00:12:00:00/e0 tag 0 dma 28672 out
Apr 10 20:47:56 localhost kernel:         res
61/04:28:38:6a:56/00:00:12:00:00/e0 Emask 0x1 (device error)
Apr 10 20:47:56 localhost kernel: ata8.00: status: { DRDY DF ERR }
Apr 10 20:47:56 localhost kernel: ata8.00: error: { ABRT }
Apr 10 20:47:56 localhost kernel: ata8.00: both IDENTIFYs aborted,
assuming NODEV
Apr 10 20:47:56 localhost kernel: ata8.00: revalidation failed (errno=-2)
Apr 10 20:47:56 localhost kernel: ata8: hard resetting link
Apr 10 20:47:57 localhost kernel: ata8: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
Apr 10 20:47:57 localhost kernel: ata8.00: both IDENTIFYs aborted,
assuming NODEV
Apr 10 20:47:57 localhost kernel: ata8.00: revalidation failed (errno=-2)
Apr 10 20:48:02 localhost kernel: ata8: hard resetting link
Apr 10 20:48:03 localhost kernel: ata8: SATA link up 1.5 Gbps (SStatus 113
SControl 310)
Apr 10 20:48:03 localhost kernel: ata8.00: both IDENTIFYs aborted,
assuming NODEV
Apr 10 20:48:03 localhost kernel: ata8.00: revalidation failed (errno=-2)
Apr 10 20:48:03 localhost kernel: ata8.00: disabled
Apr 10 20:48:03 localhost kernel: ata8: EH complete
Apr 10 20:48:03 localhost kernel: sd 13:0:0:0: [sdc] Result: hostbyte=0x04
driverbyte=0x00
Apr 10 20:48:03 localhost kernel: end_request: I/O error, dev sdc, sector
307653160
Apr 10 20:48:03 localhost kernel: Aborting journal on device dm-0:8.
Apr 10 20:48:03 localhost kernel: sd 13:0:0:0: [sdc] Result: hostbyte=0x04
driverbyte=0x00
Apr 10 20:48:03 localhost kernel: end_request: I/O error, dev sdc, sector
307652928
Apr 10 20:48:03 localhost kernel: Buffer I/O error on device dm-0, logical
block 26247168
Apr 10 20:48:03 localhost kernel: lost page write due to I/O error on dm-0
Apr 10 20:48:03 localhost kernel: JBD2: I/O error detected when updating
journal superblock for dm-0:8.
Apr 10 20:48:03 localhost kernel: ext4_abort called.
Apr 10 20:48:03 localhost kernel: EXT4-fs error (device dm-0):
ext4_journal_start_sb: Detected aborted journal
Apr 10 20:48:03 localhost kernel: Remounting filesystem read-only
Apr 10 20:48:04 localhost kernel: sd 13:0:0:0: [sdc] Result: hostbyte=0x04
driverbyte=0x00
Apr 10 20:48:04 localhost kernel: end_request: I/O error, dev sdc, sector
100044976
Apr 10 20:48:04 localhost kernel: sd 13:0:0:0: [sdc] Result: hostbyte=0x04
driverbyte=0x00
[...]

Now I believe that the drive isn't really failing,  but the errors occured
due to it having to less power to complete IO requests properly. The ext4
filesystem on it appears to be sane. I will update my backup nonetheless
for safety.

Is there a way to validate this theory? If it holds true, is there a way
to reset the relocated sector count and reuse those sectors? I think
there could be a lowlevel format tool from Samsung, but if it all
possible I'd like to avoid to erase and restore the data on the drive. Is
there a lossless way to tell the drive to retry the blocks it mapped out
and reset the relocated block count?

Pointers to relevant information is enough. Attached is output of
smartctl -a for the drive. I use self-built Linux kernel debian package:

shambhala:~> cat /proc/version
Linux version 2.6.28.8-tp42-toi-3.0-2009-03-13-v1 (martin@shambhala) (gcc
version 4.3.2 (Debian 4.3.2-1.1) ) #1 PREEMPT Tue Mar 17 13:34:24 CET
2009

Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Smartmontools-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/smartmontools-support

smartctl-a-2009-04-10-failing-now.txt (6K) Download Attachment
signature.asc (204 bytes) Download Attachment
Loading...