Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: HPT372A und Soft-RAID: Fehler

2 views
Skip to first unread message
Message has been deleted
Message has been deleted

Sven Hartge

unread,
Jun 29, 2006, 4:46:35 AM6/29/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:

> | Jun 28 21:01:00 linux2 kernel: hde: dma_intr: error=0x40 {
> | UncorrectableError }, LBAsect=66848953, high=3, low=16517305,
> | sector=64792632

> Dazu einige Fragen:
> - Kann ich wohl davon ausgehen, dass die /dev/hde hinüber ist?

Ja.

> - Wenn ich jetzt hde durch eine neue Platte (selbes Modell) ersetze,
> wird Linux dann das RAID selbständig wieder aufbauen?

Nein. Du musst es schon noch korrekt partitionieren und dann mit mdadm
dem RAID beifügen.

> Das Problem ist, dass die Swap-Partition auf hde liegt und der
> Rechner m. W. auch von dieser Platte startet. Aber theoretisch sollte
> der Rechner wegen der Spiegelung doch auch von hdg starten können,
> oder? (Abgesehen von der dann fehlenden Swap-Partition.)

Richtig. Lediglich den GRUB (oder was du auch immer benutzt) solltest du
vorher noch auf hdg installieren. Sicherheitshalber solltest du aber
eine mit grub-floppy präparierte Diskette bereithalten, nur für alle
Fälle.

--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/

Sven Hartge

unread,
Jun 29, 2006, 4:51:12 AM6/29/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:

> | 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 7
> | 196 Reallocated_Event_Count 0x0032 193 193 000 Old_age Always - 7
> | 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 5
> | 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 3

Gerade die letzten Beiden sind übel. Current_Pending_Sector sind
Sektoren, die zum Lesen als defekt markiert sind und beim nächsten
Schreibvorgang geprüft werden. (Diese können auch beim plötzlichen
Stromausfall entstehen, wenn ein Sektor nur halb geschrieben werden kann
und daher die Checksumme nicht passt. Das korrigiert sich aber beim
nächsten Schreiben von selbst.)

Offline_Uncorrectable sind Sektoren, die die Platte auch im Offline-Scan
nicht mehr lesen und wieder korrigieren konnte. Diese Sektoren sind also
tot.

Vermutlich wird bei z.B. einem badblock-scan (ein dd if=/dev/zero
of=/dev/hda bewirkt aber das gleiche) die Current_Pending_Sector wieder
auf 0 gehen, und die Reallocated_Sector_Ct um den Wert
Current_Pending_Sector+Offline_Uncorrectable steigen.

_Ich_ würde die Platte in diesem Zustand dem Händler retournieren bzw.
Einschicken oder höchsten noch als Türstopper verwenden.

Message has been deleted

Sven Hartge

unread,
Jun 29, 2006, 11:11:24 AM6/29/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:
> Sven Hartge wrote:

>> Gerade die letzten Beiden sind übel. Current_Pending_Sector sind
>> Sektoren, die zum Lesen als defekt markiert sind und beim nächsten
>> Schreibvorgang geprüft werden. (Diese können auch beim plötzlichen
>> Stromausfall entstehen, wenn ein Sektor nur halb geschrieben werden
>> kann und daher die Checksumme nicht passt. Das korrigiert sich aber
>> beim nächsten Schreiben von selbst.)

> Stromausfall gibt es da dank USV eigentlich nicht. Wie genau liest man
> denn die SMART-Werte? Ich dachte, je niedriger der Wert, desto schlechter?

Nein, nicht bei den RAW_Values.

Interessant sind eigentlich die Werte von VALUE in Relation zur THRESH,
denn das sind die normalisierten Werte, welche dem von dir genannten
Prinzip folgen.

Allerdings heißt das bei den meisten Platten, das selbst 100 Remappte
Sektoren noch zu einem Bestehen des Health Checks führen.

Ich neige dazu, selbst Platten mit wenigen remappten Sektoren
auszusondern.

> Die andere Platte (hdg) liefert folgendes:

> | ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> | 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
> | 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 0x0012 200 200 000 Old_age Always - 0

Ist doch bestens, was willst du denn?

> Sollte ich die 2. Platte gleich mit entsorgen? Das würde meine Wochenend-
> planung etwas durcheinanderwerfen ;-)

>> _Ich_ würde die Platte in diesem Zustand dem Händler retournieren bzw.
>> Einschicken oder höchsten noch als Türstopper verwenden.

> Tja, die Platte ist für Händler-Gewährleistung zu alt und die WD-Garantie
> läuft am 04.07. ab... Also wohl eher Türstopper ;-)

Wenn du _jetzt_ einen RMA bei WD beantragst und die Platte dann schnell
zur Post bringst, dann sollte das noch durchgehen.

Message has been deleted

Sven Hartge

unread,
Jun 29, 2006, 1:47:12 PM6/29/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:

> Ist beim Austausch folgendes Vorgehen korrekt?
> - Rechner herunterfahren
> - Defekte Festplatte wechseln
> - Rechner hochfahren (ggf. mit Rescue-Disk, obwohl laut Doku LILO auf
> beiden Platten sein sollte) und hoffen, dass SuSE auch vom halben
> Array bootet ;-)

Platte partitionieren. Ich vermute einmal, dass du nur eine Partition im
RAID hast und nicht die komplette Platte.

> - Neue Platte mit "raidhotadd /dev/md0 /dev/hdX" einbinden und mit
> cat /proc/mdstat dem Resync-Prozess zuschauen.

Ja.

> - Das ganze ggf. wiederholen, um die 2. Platte ebenfalls zu tauschen.

Korrekt. Aber warum willst du die zweite Platte tauschen? Die ist
bestens in Schuss.

> Woher weiß Linux eigentlich, welche Platte auf welche gespiegelt werden
> muss?

Weil auf der alten Platte eine gültige RAID-Signatur ist und auf der
neuen nicht.

Message has been deleted

Sven Hartge

unread,
Jun 29, 2006, 5:38:32 PM6/29/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:
> Sven Hartge wrote:

>> Platte partitionieren. Ich vermute einmal, dass du nur eine Partition
>> im RAID hast und nicht die komplette Platte.

> Ach so, ja. Also mit fdisk entsprechend (genau wie die alte)
> partitionieren und dann raidhotadd /dev/md0 /dev/hdXY (also die
> *Partition*), korrekt?

Genau. Auf korrekten Typ (fd) achten.

>>> Woher weiß Linux eigentlich, welche Platte auf welche gespiegelt
>>> werden muss?
>> Weil auf der alten Platte eine gültige RAID-Signatur ist und auf der
>> neuen nicht.

> Ach so. Danke!

Bzw. weil auf der neuen Partition in den Meta-Daten steht, dass sie die
neue ist.

Message has been deleted

Sven Hartge

unread,
Jul 7, 2006, 5:55:04 PM7/7/06
to
Philipp v. Thunen <thisaddress...@pvth.info> wrote:

> Problematisch war aber, dass SuSE den LILO-Bootloader nur auf hde (die
> auszutauschende Platte) installiert hat. Da LILO sich aber auch nicht
> einfach auf hdg installieren lassen wollte (keine Fehlermeldung, aber
> trotzdem kein Start von der Platte möglich) und ich sowieso schon
> entnervt war, habe ich kurzerhand mit dd die defekte Platte auf die
> Austauschplatte kopiert (damit LILO, die Partitionierung usw. direkt
> übernommen wurden) und dann neu ins RAID eingebunden, jetzt läuft
> alles wieder. Danke nochmal, Sven!

Ich empfehle dir _dringend_ das Urtum LILO zu entsorgen und statt dessen
einen zeitgemäßeren Bootloader wie z.B. GRUB zu verwenden. Dann hättest
du bei deinem Problem im dümmsten Falle einfach nur eine GRUB-Floppy
einlegen müssen und hättest dann davon a) dein System booten oder b)
gleich den Bootloader selbst reinstallieren können.

0 new messages