Festplatte kontrollieren (was: Re: )

Florian Gross florian at grossing.de
Son Dez 13 06:02:34 GMT 2009


Am So Dezember 13 2009 glaubte Luise Kunkle zu wissen:
> On Wed, 9 Dec 2009, Florian Gross wrote:
> > Am Di Dezember 8 2009 glaubte Gitano zu wissen:
> >> Luise Kunkle wrote:
> >>
> >>> Vielleicht ist die hd dabei, sich zu verabschieden - das wäre wohl noch
> >>> eine Möglichkeit.

> >>  - Festplattentest: Macht erst dann Sinn, wenn die o. g. Kontrollen
> >> negativ verlaufen. Ein Test mit:
> >>
> >>    'badblocks -b512 -c65536 -fsvn /dev/sd*'
> >>
> >> gehört bei mir zur Standardroutine. Dabei bleiben die Daten auf der
> >> Festplatte erhalten.
> >
> > Und einfach mal /var/log/messages checken, ob da was verdächtiges
> > auftaucht. Falls logrotate oder ähnliches aktiv ist, auch sowas wie
> > /var/log/messages-[DATUM].gz
> >
> Keine Ahnung, welches Datum ich da auswählen würde - und ob ich etwas 
> "verdächtiges" erkennen würde, ist auch noch die Frage. Ich meine - was 
> wäre da verdächtig???:-o

Das jüngste Datum erst mal. Erstmal wäre alles verdächtig, wo die hd
auftaucht.

Das Datumsformat ist übrigens in der Regel JJJJMMDD.

Also wäre 20091213 der 13.12.2009.

Zum Rumspielen kannst du dir jüngsten Dateien mal nach ~/test oder so
kopieren, Rechte anpassen, auspacken und als normaler User ein wenig
mit grep üben. ;-)

Sowas in der Art:

$grep sda messages-20091213 > sda.log
$cat sda.log

Bei mir kommt da z.B.

Dec 13 02:17:43 florian smartd[4833]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 58 to 57
Dec 13 02:17:43 florian smartd[4833]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 43

In dem Zusammenhang uninteressant.

Also

$grep -v Temperature sda.log > sda2.log

Dann schau mal nach, was in sda2.log überlebt hat.

Ja, es geht bestimmt eleganter, aber ich gehöre ins Bett und die
kleinen Fingerübungen sind für Anfänger auch interessant. ;-)
 
> > Sind SMART- Daten verfügbar?
> >
> > smartctl -a /dev/sdX
> >
> Jede menge Daten - die mir auch nichts sagen, es scheinen aber keine 
> errors da zu sein. War aber rasend schnell - kann man dabei überhaupt was 
> finden??? :-o

Dann grenz das doch etwas ein ;-)

$smartctl -a /dev/sda | grep -A 25 Thresholds

sollte die relevanten Daten auswerfen (bei mir reicht -A 20).

So sieht das bei mir aus:
(die uninteressanten letzten 3 Zeilen gesnipt)

$florian:/home/florian # smartctl -a /dev/sdc | grep -A 20 Thresholds
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0003   191   182   021    Pre-fail  Always       -       5416
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       465
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   066   066   000    Old_age   Always       -       25444
 10 Spin_Retry_Count        0x0013   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       449
190 Airflow_Temperature_Cel 0x0022   059   042   045    Old_age   Always   In_the_past 41
194 Temperature_Celsius     0x0022   109   092   000    Old_age   Always       -       41
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       43
200 Multi_Zone_Error_Rate   0x0009   200   200   051    Pre-fail  Offline      -       0

In dem Block sollten sich Hinweise finden lassen.
BTW: Diese Platte hat 25444 Stunden auf dem Buckel *g*
Ich sollte sie im Auge behalten.

Übrigens: Liest du eigentlich auch vorher nach, was dir genannte
Befehle eigentlich machen? Bei manchen Befehlen können Tippfehler
böse Auswirkungen haben oder der Schreiberling ist böse und schreibt
absichtlich Mist... nur mal so nebenbei.

Doku lesen beugt da Ärger vor.

BTW: http://wiki.ubuntuusers.de/Festplattenstatus dürfte für dich
interessant sein.

Und sonst: Suchmaschine mit smartctl füttern, da kommen eigentlich
brauchbare Ergebnisse, was wie zu lesen ist.

> Der Mensch im Computerladen hat bestätigt, dass es praktisch unmöglich 
> ist, rauszufinden, ob der Festplatten Controller defekt ist oder die 
> Platine oder das mb.
>
> Allerdings hat er mir auch gesagt, dass er auf seinem ubuntu auch schon öfter mal 
> Programme "verloren" hat :-o. Also vielleicht doch nicht die hardware:-)

Solange man da nicht genau weiß, was er da gemacht hat und welche
Programme da genau beteiligt waren und ob man die Hardware sicher
ausschließen kann, gehe ich von einem Problem an der Tastatur aus.

Aus Erfahrung. Die einzigen Datenverluste unter Linux waren unbedachte
Aktionen meinerseits. rm -rf *.* als root oder solche Späße
(funktioniert das eigentlich noch, daß da gleich . und .. mit
erwischt werden? Ich mags ned testen, vor neun Jahren waren 3
Festplatten leergeräumt... Obwohl, ich sollte endlich mal den
Testrechner aufsetzen... *g*)

flo
-- 
Hörst du einen WoKo röhren,
schick ihn nach dag°, da wird er nicht stören.       [Dieter Bruegmann in dtb]