Hallo!
Kennt ihr irgendein Tool, verzugsweise unter Debian Linux lauffähig,
welches die SMART-Informationen einer Festplatte zurücksetzen kann?
Hintergrund: Ich hab eine feine 500GB-2,5-Zoll-SATA-Platte von Samsung in
ein externe USB/eSATA-Gehäuse gebaut. Ohne Power over eSATA gibts keinen
Strom, also lag dem Gehäuse ein USB-Stromkabel bei. Mit zwei Anschlüssen.
Ich hab nun einmal den Fehler gemacht, nicht den "Haupt"-Stecker mit dem
USB-Port zu verbinden, sondern den zweiten, der offenar zur Unterstützung
gedacht ist für USB-Hubs und Notebooks, die auf einem USB-Port nicht
genügend Saft gibt. Nun bekommt die Festplatte komischerweise, wenn sie
mit dem zweiten USB-Stecker mit dem Notebook verbunden ist, offenbar nicht
genügend Strom. Zumindest ist sie mir während eines rsync-Backups immer
wieder vom Bus verschwunden.
Ich brauchte ne Weile, um den Zusammenhang herauszufinden, und sie
verschwand so 2-3 Mal vom Bus, bevor ich raffte, was vor sich ging. Danach
nach ich den Haupt-Stecker und es funktionierte alles wie gehabt.
Dummerweise hat die Platte sich die Sache gemerkt und liefert nun SMART
failed zurück und ich bekomme von smartctl den dezenten Hinweis, dass ich
die Platte doch binnen 24 Stunden austauschen soll. Das war vor Wochen
schon und die Platte läuft einwandfrei.
Ich möchte jetzt gerne die Platte dazu veranlassen, die SMART-
Informationen zurückzusetzen und auch die Grown-Defect-Liste, die es
wahrscheinlich ja auch bei SATA gibt, zu löschen. Ich hab scsiformat und
ein weiteren ähnlichen Befehl versucht, die weigern sich jedoch über SATA
zu funktionieren. Ich hab ein Tool, glaub HDD Cleaner unter Windows
versucht.
Es bleibt jetzt noch das Tool vom Hersteller. ES-Tool. Das ist auch der
Hinweis, den ich vom Support bekommen hab. Auf die Frage, inwiefern es
jedoch die SMART-Informationen zurücksetzt, habe ich jedoch keine klare
Antwort bekommen. Und dummerweise erkennt das weder USB-Platten nur den
PCMCIA eSATA-Controller. Und ich hab eben nur meine zwei Notebooks. Ich
werd das schon mal in irgendeinem Computer ausprobieren, wenn es gar nicht
anders geht.
Doch vorher hier nochmal meine Frage, ob jemand dazu irgendetwas weiß. Ich
hab bereits eine Mail an smartmontools-support geschrieben, doch die blieb
unbeantwortet. Scheint also nicht so eine ganz triviale Frage zu sein. Ich
weiß jedoch, dass hier ein Haufen Admins mitlesen, von denen vielleicht
jemand schonmal so ein Problem gehabt hat.
Kann auch sein, dass auf der smartmontools-Liste niemand geantwortet hat,
da dies auch etwas kritisch gesehen werden kann. Jemand könnte die
Informationen zurücksetzen und dann die Platte als neu verkaufen. Das hab
ich jedoch nicht vor, denn ich bin mir ziemlich sicher, dass die Platte
noch vollkommen einwandfrei bin. Und auch sonst, würde ich sowas nicht
machen. So oder so würde ich denke ich jedoch einen Badblock-Scan
drüberlaufen lassen, um wirklich sicher zu gehen.
Momentane Heransgehensweise ist halt einfach, den SMART-Status zu
ignorieren und allenfalls einen Blick auf die konkreten SMART-Werte zu
werfen. Im Grunde ists ja schon eine recht hochtrabende Sache. Über USB
würd ich den SMART-Status so ohne weiteres ja ohnehin nicht rausbekommen.
Dennoch läßt es mir nicht so recht die Ruhe und mir will nicht in den
Kopf, dass sich diese Informationen nichz zurücksetzen lassen.
Andererseits, wenn es zu aufwendig würd, belasse ich es möglicherweise
wirklich dabei.
Nunja, vielleicht ists für den ein oder anderen ja ne interessante
Fragestellung! ;-)
Ciao,
Martin
--------- Weitergeleitete Nachricht ----------
Subject: [smartmontools-support] Samsung drive reports to high relocated
sector count
Date: Freitag 10 April 2009
From: Martin Steigerwald <Martin@lichtvoll.de>
To: smartmontools-support@lists.sourceforge.net
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
-------------------------------------------------------
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.