Re: [OT] SMART-Informationen auf SATA-Festplatte zurücksetzen
Ohne das jetzt genau zu wissen, würde ich mal behaupten, dass das
Zurücksetzen der SMART Daten wohl gar nicht vorgesehen ist. Einer der
Gründe könnte der von dir genannte sein, dass man die Platte als neu
verkaufen könnte.
Aber vielleicht als Idee (selbst nicht getestet), vielleicht hilft es
ja, wenn du mal einen ausführlichen Self-Test durchlaufen lässt. Glaube
es zwar selbst weniger, aber man weiß ja nie so genau.
Gruß
Flo
Am Sonntag, den 31.05.2009, 15:08 +0200 schrieb Martin Steigerwald:
> 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
>
> -------------------------------------------------------
>
>
--
Florian Sievers <florian@dynamic-core.ath.cx>
Reply to: