Um badblocks herum partitionieren
Hallo Leute, kleiner Lacher vorweg: Ich habe gerade einen Rechner hierstehen, auf dem /home "plötzlich" leer war. Nunja, die Ursache hat sich nach einem Blick in /root/.bash_history recht schnell geklärt: cd /backup/storebackup2/ rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! ^^ Das Leerzeichen war zuviel :-( Nein, ich war das nicht. Zur eigentlichen Frage: Die Festplatte [1] hat einige badblocks [2], um die ich gern herumpartitionieren würde. Eine Neuinstallation ist ja eh fällig *g* Leider ist mir nicht klar, wie ich die Badblocks-Nummern in Werte (Zylinder) umrechnen kann, die von fdisk verstanden werden. Kann mir das jemand erklären? (Eine Beispielrechnung a la "Block 63000 liegt auf Zylinder XY" reicht mir eigentlich. Ich bin aber auch nicht böse, wenn jemand gleich einen kompletten Partitionierungsvorschlag macht ;-) Gruß Christian Boltz [1] Ein paar Daten zur Platte: ==> fdisk -l <== Platte /dev/hda: 30.7 GByte, 30736613376 Byte 255 Köpfe, 63 Sektoren/Spuren, 3736 Zylinder Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp /dev/hda1 * 1 1588 12755578+ 83 Linux /dev/hda2 1589 1654 530145 82 Linux Swap /dev/hda3 1720 2503 6297480 83 Linux /dev/hda4 2504 3736 9904072+ f Win95 Erw. (LBA) /dev/hda5 2504 3736 9904041 83 Linux ==> /proc/ide/hda/capacity <== 60032448 ==> /proc/ide/hda/geometry <== physical 59556/16/63 logical 3736/255/63 ==> /proc/ide/hda/model <== Maxtor 33073H3 [2] # badblocks /dev/hda 63000 63001 63002 63003 198264 198265 198266 198267 198268 198269 198270 198271 234848 474032 474033 474034 474035 746104 746105 746106 746107 746108 746109 746110 746111 -- Im Dunkeln sind offensichtlich alle Mailinglisten grau. ;) [Andreas Kneib in suse-linux]
Hallo, Am Sat, 22 Oct 2005, Christian Boltz schrieb:
kleiner Lacher vorweg:
Ich habe gerade einen Rechner hierstehen, auf dem /home "plötzlich" leer war. Nunja, die Ursache hat sich nach einem Blick in /root/.bash_history recht schnell geklärt:
cd /backup/storebackup2/ rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! ^^ Das Leerzeichen war zuviel :-(
*MUAHAHAHAHAHAAAA*
Nein, ich war das nicht.
*hehe*
Zur eigentlichen Frage:
Die Festplatte [1] hat einige badblocks [2], um die ich gern herumpartitionieren würde. Eine Neuinstallation ist ja eh fällig *g*
Kurze Antwort: Vergiss es. Die Badblocks sind ziemlich verteilt. Die Platte duerfte sich rapide dem Orkus naehern... Und _FALLS_ du die Platte noch einer Zweitverwertung als Squid-Cache zufuehren willst, dann partitioniere eher grosszuegig drum rum. Partitioniere so, dass die Partitionsgrenzen weit weg von den badblocks sind und lass dann die defekten Bloecke von mke2fs/badblocks einfach als "dummy-Datei" "ausblenden" (hab ich mal so mit ner Diskette gemacht -> man badblocks es wird ne Datei namens ".badblocks" angelegt, die die defekten Bloecke belegt).
Leider ist mir nicht klar, wie ich die Badblocks-Nummern in Werte (Zylinder) umrechnen kann, die von fdisk verstanden werden.
Hm. Ich kenn badblocks nur partitionsweise. Vgl. 'man badblocks' Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, wo sich das 'blocks' auf die Bloecke einer ext2/3 Partition bezieht, also zwischen 1 und 4 KB (also 2-8 Sektoren).
Kann mir das jemand erklären? (Eine Beispielrechnung a la "Block 63000 liegt auf Zylinder XY" reicht mir eigentlich. Ich bin aber auch nicht böse, wenn jemand gleich einen kompletten Partitionierungsvorschlag macht ;-)
Kommt auf das FS an (s.o.). Je nachdem wie gross die FS-Bloecke sind kannst du in Sektoren und damit dann via
==> fdisk -l <== Platte /dev/hda: 30.7 GByte, 30736613376 Byte 255 Köpfe, 63 Sektoren/Spuren, 3736 Zylinder Einheiten = Zylinder von 16065 * 512 = 8225280 Bytes
in Zylinder umrechnen...
Gerät boot. Anfang Ende Blöcke Id Dateisystemtyp /dev/hda1 * 1 1588 12755578+ 83 Linux
==> /proc/ide/hda/model <== Maxtor 33073H3
Hm. 30 GB mit 3*Hx von Maxtor??? Duerfte so ca. 4 Jahre alt sein, korrekt? Ist aber auf jeden Fall ein komisches Modell, das passt nicht so recht in die Modelllinien (IIRC[3]).
[2] # badblocks /dev/hda 63000 .. 63003 198264 .. 198271 234848 474032 .. 474035 746104 .. 746111
Das muesste alles auf hda1 liegen, das umfasst ja aber auch fast die halbe Platte... Ich wuerde der Platte jedenfalls keine Daten mehr anvertrauen. Und als Cache (s.o.) wuerde ich nur den Bereich der Blocks 1000000 - Ende (Blocks a 4 KB = default) verwenden, also die Sektoren ab LBA 8000000, also fast das ganze hda1 (geht bis LBA 12000000) weglassen. Die Rechnerei spare ich mir. Die Platte hat jetzt (oder vor laengerem unbemerkt) obige Sektoren verloren, aber generell sind alle Sektoren, die badblocks als defekt erkennen kann solche, die defekt gegangen sind _NACHDEM_ die (durchaus nicht knapp bemessenen) Reservesektoren der Platte aufgebraucht wurden. D.h. schon der erste defekte Sektor den du zu sehen bekommst bedeutet, dass die Platte alle Reservesektoren (AFAIR durchaus im Prozentbereich! 1-5% oder so!) aufgebraucht hat... Es kann aber durchaus sein (so lehrt die Erfahrung), dass die Platte quasi einmalig einen Haufen Sektoren auf einmal verliert, und der Rest dann noch Jahre tut, wahrscheinlicher (zu wohl >>90%) ist aber, dass der Rest der Sektoren auch bald das zeitliche segnen wird. BTW: kann die Platte schon SMART? Und ggfs. kann man nochmal badblocks laufen lassen und die Sektornummern (LBA) die im syslog auftauchen notieren. Aeh, also, ich halte die Platte fuer einen Fall fuer's Recycling... -dnh PS: melde dich ggfs. mit mehr Details, per PM, falls du's riskieren willst. [3] kann mich taeuschen, inzwischen scheine ich mich an eine 3*er Modellreihe zu erinnern, aber immer noch nicht an das *H? dazu. Da muesste ich mal alte c'ts rauskramen und dort die Festplatten- karussels bzw. die Anzeigen z.B. von Alternate anschauen... --
There is of course also Advocaat, aka "alcoholic custard" [..]. Especially if you've got a bottle with a dodgy lid and then eagerly follow the instructions to shake before use. -- Peter Ah. Alcoholic bukkake. -- Jim
Hallo, Am Samstag, 22. Oktober 2005 06:13 schrieb David Haller:
cd /backup/storebackup2/ rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! ^^ Das Leerzeichen war zuviel :-(
*MUAHAHAHAHAHAAAA*
Wenn ich richtig verstanden habe hat dieser rm das gesamte home-Verzeichnis gelöscht. Warum? Gruss Karl
Moin,
On Sat, 22 Oct 2005 09:56:38 +0200
Karl Sinn
Am Samstag, 22. Oktober 2005 06:13 schrieb David Haller:
cd /backup/storebackup2/ rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! ^^ Das Leerzeichen war zuviel :-(
*MUAHAHAHAHAHAAAA*
Wenn ich richtig verstanden habe hat dieser rm das gesamte home-Verzeichnis gelöscht.
Warum?
Vermutlich, weil es in der internen Struktur des Dateisystems recht weit "oben" aufgehängt war. Denn eigentlich hätte der Befehl ja buchstäblich nichts übriglassen sollen. $ rm -r ... ist rekursives Löschen. Und wenn man das von "/" macht, dann heißt rekursiv: alles. Dass das rm vorher noch wie befohlen das Verzeichnis 2005... weggeputzt hat, ist dann auch wurscht. rm verträgt also mehr als nur ein angegebenes Verzeichnis (oder Datei). Gruß, -hwh
Am Samstag, 22. Oktober 2005 09:56 schrieb Karl Sinn:
Am Samstag, 22. Oktober 2005 06:13 schrieb David Haller:
cd /backup/storebackup2/ rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! ^^ Das Leerzeichen war zuviel :-(
Wenn ich richtig verstanden habe hat dieser rm das gesamte home-Verzeichnis gelöscht.
Warum?
Mal sehen, ob ich es richtig verstanden habe: man rm sagt: -r, -R, --recursive remove the contents of directories recursively info bash 's &': If a command is terminated by the control operator `&', the shell executes the command asynchronously in a subshell. Also: Es wird das Verzeichnis/die Datei "2005.09.03_04.26.25" und das Verzeichnis / im Hintergrund ohne Nachfrage rekursiv gelöscht. Als User ausgeführt bleibt alles über, worauf er keine Löschrechte hat. Ohne Leerzeichen wäre alles im und das Verzeichnis "2005.09.03_04.26.25" verschwunden. wolfgang
Moin nochmal,
kleine unwichtige Ergänzung:
On Sat, 22 Oct 2005 14:09:05 +0200
Wolfgang Denda
Also: Es wird das Verzeichnis/die Datei "2005.09.03_04.26.25" und das Verzeichnis / im Hintergrund ohne Nachfrage rekursiv gelöscht. Als User ausgeführt bleibt alles über, worauf er keine Löschrechte hat.
Wurde hier allerdings wohl als root ausgeführt, wenn's in der /root/.bash_history stand. Da wird wohl noch jemand panisch ein kill oder ein fg + CTRL-C hinterhergejagt haben :-) Gruß, -hwh
Hallo Hans-Werner, hallo Leute, Am Samstag, 22. Oktober 2005 14:32 schrieb Hans-Werner Hilse:
On Sat, 22 Oct 2005 14:09:05 +0200 Wolfgang Denda wrote:
Also: Es wird das Verzeichnis/die Datei "2005.09.03_04.26.25" und das Verzeichnis / im Hintergrund ohne Nachfrage rekursiv gelöscht. Als User ausgeführt bleibt alles über, worauf er keine Löschrechte hat.
Wurde hier allerdings wohl als root ausgeführt, wenn's in der /root/.bash_history stand. Da wird wohl noch jemand panisch ein kill oder ein fg + CTRL-C hinterhergejagt haben :-)
Ich vermute eher, dass rm beim ersten Fehler seine Arbeit abgebrochen hat. Der erste Fehler war vermutlich, dass /home nicht gelöscht werden konnte - Grund: es ist eine eigene Partition und war noch gemountet. Der Mountpoint ist also "busy" ;-) Mit rm -rf wäre das Löschen vermutlich trotz des Fehlers weitergelaufen. Durch einen "glücklichen" Zufall scheint das Löschen in /home angefangen zu haben. Die Systemverzeichnisse scheinen noch OK zu sein, zumindest bootet der Rechner noch problemlos. Auch /backup (die Hauptnutzung dieses Rechners) wurde glücklicherweise verschont. Ach ja, mangels ernsthafter Nutzung lagen in /home eher unwichtige Daten :-) Gruß Christian Boltz -- Naja, zumindest war Maxtor "weitsichtig": mit einer 48bit-Adressierung kann man 134217728 GB (128 Petabyte) ansprechen, das sollte eigentlich fuer ein paar Jaehrchen reichen, oder? ;)) [David Haller in suse-linux]
Hallo David, hallo Leute, Am Samstag, 22. Oktober 2005 06:13 schrieb David Haller:
Am Sat, 22 Oct 2005, Christian Boltz schrieb:
Die Festplatte [1] hat einige badblocks [2], um die ich gern herumpartitionieren würde. Eine Neuinstallation ist ja eh fällig *g*
Kurze Antwort: Vergiss es. Die Badblocks sind ziemlich verteilt. Die Platte duerfte sich rapide dem Orkus naehern...
Und _FALLS_ du die Platte noch einer Zweitverwertung als Squid-Cache zufuehren willst, dann partitioniere eher grosszuegig drum rum. Partitioniere so, dass die Partitionsgrenzen weit weg von den badblocks sind und lass dann die defekten Bloecke von mke2fs/badblocks einfach als "dummy-Datei" "ausblenden" (hab ich mal so mit ner Diskette gemacht -> man badblocks es wird ne Datei namens ".badblocks" angelegt, die die defekten Bloecke belegt).
Wenn, dann lege ich auf dem betroffenen Bereich gar keine Partition an (bzw. eine unformatierte, damit keine "Lücken" da sind).
Leider ist mir nicht klar, wie ich die Badblocks-Nummern in Werte (Zylinder) umrechnen kann, die von fdisk verstanden werden.
Hm. Ich kenn badblocks nur partitionsweise. Vgl. 'man badblocks'
Important note: If the output of badblocks is going to be fed to the e2fsck or mke2fs programs,
wo sich das 'blocks' auf die Bloecke einer ext2/3 Partition bezieht, also zwischen 1 und 4 KB (also 2-8 Sektoren).
Ich bin gerade darauf gekommen, dass badblocks die Gesamtzahl der Blöcke selbst verrät. Man muss nur auf eine Fortschrittsanzeige bestehen ;-) # badblocks -s /dev/hda Suche nach defekten Blöcken (Nur-Lesen-Modus): 18848/ 30016224 Voila, badblocks hat die Platte also in 30.016.224 Sektoren aufgeteilt. Bei einer 30GB-Platte heißt das Sektoren a 1k. Die Badblocks erstrecken sich somit auf den Bereich der ersten 750 MB. Ich werde also sinnvollerweise (mindestens) auf das erste GB der Platte verzichten. Dass ich die Platte überwachen und wohl auch ersetzen muss, ist mir schon klar.
==> /proc/ide/hda/model <== Maxtor 33073H3
Hm. 30 GB mit 3*Hx von Maxtor??? Duerfte so ca. 4 Jahre alt sein, korrekt?
Gute Frage, da es nicht mein Rechner ist. *such* Der Prozessor ist ein AMD Duron 800 MHz, die 4 Jahre dürften also in etwa hinkommen. [gute Erklärung weggekürzt]
Die Platte hat jetzt (oder vor laengerem unbemerkt) obige Sektoren verloren, aber generell sind alle Sektoren, die badblocks als defekt erkennen kann solche, die defekt gegangen sind _NACHDEM_ die (durchaus nicht knapp bemessenen) Reservesektoren der Platte aufgebraucht wurden. D.h. schon der erste defekte Sektor den du zu sehen bekommst bedeutet, dass die Platte alle Reservesektoren (AFAIR durchaus im Prozentbereich! 1-5% oder so!) aufgebraucht hat...
Schon klar.
Es kann aber durchaus sein (so lehrt die Erfahrung), dass die Platte quasi einmalig einen Haufen Sektoren auf einmal verliert, und der Rest dann noch Jahre tut, wahrscheinlicher (zu wohl >>90%) ist aber, dass der Rest der Sektoren auch bald das zeitliche segnen wird.
Ich spekuliere einfach mal auf den ersten Fall ;-)
BTW: kann die Platte schon SMART?
/proc/ide/hda/smart_thresholds und /proc/ide/hda/smart_values existieren jedenfalls. Ich installiere dann wohl demnächst den smartd ;-) Gruß Christian Boltz --
[Strings in C] Das würde alles nur Aussagen über die glibc erlauben. Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [> Thorsten Haude und Jan Trippler in suse-linux]
Christian Boltz wrote:
Zur eigentlichen Frage:
Die Festplatte [1] hat einige badblocks [2], um die ich gern herumpartitionieren würde. Eine Neuinstallation ist ja eh fällig *g*
Leider ist mir nicht klar, wie ich die Badblocks-Nummern in Werte (Zylinder) umrechnen kann, die von fdisk verstanden werden.
Ich würde es lassen. Entweder die Platte bekommt es selber hin ihre Bad-Blacks zu verwalten oder du wirst den Rechner mit ein wenig Pech schneller weider sehen als allen lieb ist. Schau dir erst mal mit einem Tools des herstellers die Platte näher an. Die Barts PE CD bringt das schon einiges mit. Es gibt aber auch noch andere System-Cds die Tools an Bord haben. Gruß
Hallo Christian,
rm -r 2005.09.03_04.26.25 /& # bitte NICHT NACHMACHEN! boeser Fehler! :( Passiert jedem nur wenige Male, aber leider gibt's sowas hin und wieder... ;)
Die Festplatte [1] hat einige badblocks [2], um die ich gern herumpartitionieren würde. Eine Neuinstallation ist ja eh fällig *g*
Leider ist mir nicht klar, wie ich die Badblocks-Nummern in Werte (Zylinder) umrechnen kann, die von fdisk verstanden werden. Kann mir das jemand erklären? (Eine Beispielrechnung a la "Block 63000 liegt auf Zylinder XY" reicht mir eigentlich. Ich bin aber auch nicht böse, wenn jemand gleich einen kompletten Partitionierungsvorschlag macht ;-) Dazu kann ich Dir das Howto der Smartmontools empfehlen:
http://smartmontools.sourceforge.net/BadBlockHowTo.txt Ich wuerde an Deiner Stelle den Versuch wagen die Platte zu retten, wobei das Argument, dass die Platte eh bald mehr Probleme machen koennte, sicherlich nicht vom Tisch zu wischen ist... Leider habe ich im letzten halben Jahr schon mit 3 (drei) Platten schlechte Erfahrungen gemacht. Mit Hilfe obiger Anleitung war es mir aber moeglich, 2 davon wieder zur zuverlaessigen Mitarbeit zu bewegen. Bei der 3. war ein sysadmin mit dem Austauschen schneller. :) Die Installation der Smartmontools selbst ist sehr hilfreich um vor sich schon andeutenden Problemen rechtzeitig gewarnt zu sein. Also, wenn Du ein bisschen Zeit investieren kannst, probier's aus. Es ist mit Sicherheit nicht umsonst! Zumindest lernt man dabei, dass man Festplatten der Neuzeit niemals trauen sollte. Vorbei die Zeiten als die 40MB-Platten in den 386/486ern jahrelang verlaesslich vor sich hinwerkelten. Die tollen Gigabyteplatten von heute sind da leider nicht mehr so robust... Gruss, Marko
Marko Kaening wrote:
[...] Die Installation der Smartmontools selbst ist sehr hilfreich um vor sich schon andeutenden Problemen rechtzeitig gewarnt zu sein. Also, wenn Du ein bisschen Zeit investieren kannst, probier's aus. Es ist mit Sicherheit nicht umsonst!
Kann ich leider nicht bestaetigen. Wir haben hier 120 neue Maxtor IDE 300 GB Festplatten gehabt, etliche davon waren nicht zu gebrauchen. Nach wenigen Wochen gaben sie bei bestimmten Aktionen die typischen Klack-Geraeusche von sich, die so eindeutig fuer kaputte Festplatten sprechen. Die smartmontools haben leider selbst nach etlichen Tests immer noch behauptet, alles sei OK (und, bevor Du fragst: ja, wir wissen, wie man die Logs zu lesen hat ;-)). Das Maxtor-eigene Festplattenanalyseprogramm hat die Fehler sofort festgestellt und einen Error-Code ausgespuckt - die Festplatten gingen zurueck an den Vertrieb/Hersteller und Maxtor hat fortan einen Kunden weniger. Mit den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig. Cheers, Th. PS: Privat habe ich ebenfalls eine Maxtor-Platte, und die bereitet keine Probleme. Vielleicht war es eben eine schlechte Serie, aber das interessiert unsere Admins natuerlich herzlich wenig, es muss schlicht funktionieren, alles andere ist zweitrangig.
On Mon, 24 Oct 2005, Thomas Hertweck wrote:
Kann ich leider nicht bestaetigen. Wir haben hier 120 neue Maxtor IDE 300 GB Festplatten gehabt, etliche davon waren nicht zu gebrauchen. ... den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig. Danke fuer den Hinweis!!! Hast Du das Problem schon mal auf der smartmontools-Liste angesprochen? Klingt ja erschreckend! Liegt dann aber wohl daran, dass SMART selbst die Platte nicht ausreichend testet. Die smartmontools selbst koennen daran kaum Schuld sein, denke ich, sondern eher die Firmware der Platten, oder?!
PS: Privat habe ich ebenfalls eine Maxtor-Platte, und die bereitet keine Probleme. Vielleicht war es eben eine schlechte Serie, aber das Ich habe eine Maxtor und eine Samsung. Die Maxtor laeuft tadellos, die Samsung hingegen macht von Anbeginn an Aerger. Bin immer noch nicht durch damit... :(
Gruss, Marko
Marko Kaening wrote:
On Mon, 24 Oct 2005, Thomas Hertweck wrote:
Kann ich leider nicht bestaetigen. Wir haben hier 120 neue Maxtor IDE 300 GB Festplatten gehabt, etliche davon waren nicht zu gebrauchen. ... den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig.
Danke fuer den Hinweis!!! Hast Du das Problem schon mal auf der smartmontools-Liste angesprochen?
Nein, ich habe leider nur begrenzt Zeit, mich um solche Dinge zu kuemmern, und es ist dann doch eher "low priority"... Wenn bei uns Hardware so offensichtlich nicht geht und kaputt ist, wird sie schlicht sofort getauscht, insofern bleibt auch nicht viel Zeit, den Dingen (wie hier beschrieben mit smartmontools) auf den Grund zu gehen - ich kann also Tests jetzt nicht wiederholen, weil die Hardware schon lange nicht mehr da ist.
Klingt ja erschreckend! Liegt dann aber wohl daran, dass SMART selbst die Platte nicht ausreichend testet. Die smartmontools selbst koennen daran kaum Schuld sein, denke ich, sondern eher die Firmware der Platten, oder?!
Die smartmontools machen eigentlich nichts anderes als die SMART Daten der Platte auslesen. Ich gehe nicht davon aus, dass es dabei zu einem Problem gekommen ist, was zu falschen Daten gefuehrt hat. Ich nehme an, die Fehler wurden schlicht von der SMART Plattentechnolgie nicht korrekt registriert bzw. geloggt.
PS: Privat habe ich ebenfalls eine Maxtor-Platte, und die bereitet keine Probleme. Vielleicht war es eben eine schlechte Serie, aber das
Ich habe eine Maxtor und eine Samsung. Die Maxtor laeuft tadellos, die Samsung hingegen macht von Anbeginn an Aerger. Bin immer noch nicht durch damit... :(
Naja, ich habe schon Festplatten unterschiedlichster Hersteller kaputt gehen sehen. 100% Garantie fuer zuverlaessige Funktionalitaet gibt es halt nicht, bei keinem Hersteller. Allerdings scheinen mir doch die Probleme mit zunehmender Dichte der Platter ueberproportional zuzunehmen. Cheers, Thomson
Datum: Tue, 25 Oct 2005 10:56:17 +0200 (CEST)
Von: Marko Kaening
On Mon, 24 Oct 2005, Thomas Hertweck wrote:
Kann ich leider nicht bestaetigen. Wir haben hier 120 neue Maxtor IDE 300 GB Festplatten gehabt, etliche davon waren nicht zu gebrauchen. ... den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig. Danke fuer den Hinweis!!! Hast Du das Problem schon mal auf der smartmontools-Liste angesprochen? Klingt ja erschreckend! Liegt dann aber wohl daran, dass SMART selbst die Platte nicht ausreichend testet. Die smartmontools selbst koennen daran kaum Schuld sein, denke ich, sondern eher die Firmware der Platten, oder?!
PS: Privat habe ich ebenfalls eine Maxtor-Platte, und die bereitet keine Probleme. Vielleicht war es eben eine schlechte Serie, aber das Ich habe eine Maxtor und eine Samsung. Die Maxtor laeuft tadellos, die Samsung hingegen macht von Anbeginn an Aerger. Bin immer noch nicht durch damit... :( Welchen Ärger? Bin nämlich im Moment auch dran, will die rausreissen, 'ne Samsung, immer mal wieder zeigt die statt der Identify irgend so 'nen Unsinn im Boot-Bereich, irgend was mit Bootcode und so, sieht ulkig aus und ist ewig lang, wusste gar nicht, dass das so lang geht. Wenn ich dann ausmache und kurz darauf ( >10 sec allerdings, denn da gibt's noch mehr Platten und die müssen erst auslaufen, Saft auf 'nen auslaufenden Motor, ist nicht so lecker) wieder an, geht's auf einmal, neulich war ich was Anderes am Fummeln, wegen der Meldung was Anderes angefangen, Rechner vergessen, lange gewartet ( >15 min mal mindestens), da ging's wieder nich', ich denk' schon, na klasse, dann geht E-Bay für die Neue ja nich', mach' wieder an, diesmal kurz nach'm ausmachen, da geht sie wieder. Die ist einfach nicht ganz in Ordnung.
Tja, zugegeben, ist Eine. Tschüß ManfredP
Gruss, Marko
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Donnerstag, 27. Oktober 2005 03:14 schrieb Manfred Preußig: [SAMSUNG] Hmm, ich bin vor etwa 1,5 Jahren komplett auf Samsung umgestiegen (mittlerweile 5 Stk) und habe bei 24/7 Betrieb bisher noch keinen Ausfall gehabt. Wollt' ich nur mal so in die Runde werfen... ;) Gruss Mario
Hallo Thomas, hallo Marko, hallo Leute, Am Montag, 24. Oktober 2005 20:18 schrieb Thomas Hertweck:
Marko Kaening wrote:
[...] Die Installation der Smartmontools selbst ist sehr hilfreich um vor sich schon andeutenden Problemen rechtzeitig gewarnt zu sein. Also, wenn Du ein bisschen Zeit investieren kannst, probier's aus. Es ist mit Sicherheit nicht umsonst!
Die smartmontools haben mir bei der Laptop-Festplatte schon mal größeren Ärger erspart, weil sie mich rechtzeitig [1] über badblocks informiert haben. Auf dem betroffenen Rechner kommen sie jetzt auch drauf - auch wenn die Platte wohl doch getauscht wird.
Kann ich leider nicht bestaetigen. Wir haben hier 120 neue Maxtor IDE 300 GB Festplatten gehabt, etliche davon waren nicht zu gebrauchen. [...] Die smartmontools haben leider selbst nach etlichen Tests immer noch behauptet, alles sei OK
Rein Interessehalber: habt Ihr die betroffenen Platten mal mit badblocks getestet?
(und, bevor Du fragst: ja, wir wissen, wie man die Logs zu lesen hat ;-)).
*g*
Mit den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig.
Zumindest ist der Einsatz der smartmontools immer noch besser als die Platte gar nicht zu überwachen. Wie gesagt - mir haben sie schonmal einen größeren Datenverlust erspart - siehe nochmal [1]. Gruß Christian Boltz [1] es hat noch zum Backup gereicht ;-) - während des Backups hat sich dann aber auch die Anzahl der defekten Sektoren *deutlich* erhöht. (Kann es sein, dass die smartmontools defekte Sektoren nur bei deren Benutzung erkennen?) Nunja, ein paar Dateien, die ich seit Ewigkeiten nicht mehr gebraucht/geändert hatte, waren kaputt, aber die hatte ich schon in diversen Backup-Instanzen ;-) -- [...] sollte für einen Ortskundigen also kinderleicht zu finden sein. Wir sind die Leute, die den dicken weißgrünen Europcar Lastwagen so bescheuert mitten auf der Straße geparkt haben. [Kristian Köhntopp zieht um]
On Wed, 26 Oct 2005, Christian Boltz wrote:
Mit den smartmontools als zuverlaessigen Indikator fuer Probleme waere ich aus dieser Erfahrung doch etwas vorsichtig.
Zumindest ist der Einsatz der smartmontools immer noch besser als die Platte gar nicht zu überwachen. Wie gesagt - mir haben sie schonmal einen größeren Datenverlust erspart - siehe nochmal [1].
Genauso ging es mir auch. Eine Platte die nach einem Crash und Recovery als wieder funktionsfaehig vom Admin ins Notebook eingebaut worden war, erwies sich nach dem einmaligen Start von smartctl als NICHT fehlerfrei. So konnte ich meine Frau vor nochmaligem Schaden bewahren, da die Platte danach durch eine neue ersetzt wurde. (Wie schon frueher einmal angedeutet hatte ich da keine Chance mit badblocks bzw. Ueberschreibversuchen der defekten Sektoren eine Selbstreparatur zu erreichen. Der Austausch war da wohl auch die bessere Alternative.) Marko
Christian Boltz wrote:
[...] Die smartmontools haben mir bei der Laptop-Festplatte schon mal größeren Ärger erspart, weil sie mich rechtzeitig [1] über badblocks informiert haben. Auf dem betroffenen Rechner kommen sie jetzt auch drauf - auch wenn die Platte wohl doch getauscht wird.
Natuerlich sind die smartmontools eine gute Sache, das habe ich nie bezweifelt, und sie koennen sehr hilfreich sein, aber wie ich schrieb sind sie mitunter eben kein *zuverlaessiger* Indikator fuer Probleme.
[...] Rein Interessehalber: habt Ihr die betroffenen Platten mal mit badblocks getestet?
Ja, bevor der PowerMax von Maxtor lief (so heisst das Tool glaube ich), lief auch ein badblocks im read-only test. Badblocks hat dabei die fehlerhaften Sektoren gefunden, und beim Versuch sie auszulesen gab es die typischen Klack-Geraeusche... Wir haben nach einer Weile den badblocks-Lauf dann abgebrochen, weil klar war, dass die Platte das Zeitliche gesegnet hat. Danach lief das Maxtor-Tool, um einen Error-Code zu bekommen, ohne den Du eine Platte nicht reklamieren kannst. Das Tool hat natuerlich die Fehler auch erkannt, allerdings war ein langer Test (lief 4h, pro Platte wohlgemerkt) noetig, der Kurztest (90s) war nicht aufschlussreich.
[...] Zumindest ist der Einsatz der smartmontools immer noch besser als die Platte gar nicht zu überwachen. Wie gesagt - mir haben sie schonmal einen größeren Datenverlust erspart - siehe nochmal [1].
Ja, dem stimme ich voll und ganz zu.
[1] es hat noch zum Backup gereicht ;-) - während des Backups hat sich dann aber auch die Anzahl der defekten Sektoren *deutlich* erhöht. (Kann es sein, dass die smartmontools defekte Sektoren nur bei deren Benutzung erkennen?)
Die smartmontools lesen eigentlich nur die SMART Daten der Platte aus. Selbst detektieren tun sie im Standardmodus erst einmal nichts. Die Platte selbst kann defekte Sektoren wahrscheinlich nur erkennen, wenn die Ansteuerung, das Schreiben oder das Lesen von Sektoren fehl schlaegt. Insofern denke ich, die Antwort auf Deine letzte Frage koennte "ja" sein. Aber ich bin kein Experte im Bereich Festplatten- und SMART-Technologie, daher ist diese Aussage nicht gesichert. Cheers, Thomson
participants (10)
-
Christian Boltz -
David Haller -
Hans-Werner Hilse -
Karl Sinn -
Manfred Preußig -
Mario van der Linde -
Marko Kaening -
Ralf Prengel -
Thomas Hertweck -
Wolfgang Denda