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

Festplatte retten?

1 view
Skip to first unread message

Eberhard Spittler

unread,
Jan 8, 2002, 12:28:07 PM1/8/02
to
Folgendes ist passiert:

1 )Auf meiner Kiste läuft Kernel 2.2.10 (von SuSE 6.2); das war der
letzte Kernel, der die Plattenkapazität auf 32 GB begrenzte.

2) Eine von vier Festplatten habe ich ausgetauscht. Die alte Platte
hatte 15 GB, die neue hat 40 GB (Fujitsu "Silent Drive"). Die anderen
haben 2, 4 und 6 GB.

3) Das BIOS steht der Platte völlig hilflos gegenüber und bleibt beim
Erkennen stehen; also habe ich sie im BIOS abgemeldet.

4) Linux erkennt sie trotzdem, aber mit CHS=16383/16/63. So war sie auch
partitionierbar, hatte aber nur 8 GB Gesamtkapazität.

Nun habe ich sie mit Kernelparametern (notlinux hdd=65535,16,63) beim
Start auf 32 GB gelupft; das ist zwar nicht alles, aber immerhin doppelt
so viel, wie ich vorher hatte.
Dann habe ich munter vor mich hin partitioniert und beim Schreiben in
die Partitionstabelle ("w" von fdisk) gab es die Fehlermeldung, daß auf
/dev/hdd nicht geschrieben werden könne. Seitdem ist die Platte im
Eimer. Wenn ich nun "fdisk /dev/hdd" aufrufe, kommt reproduzierbar die
Meldung "Unable to read /dev/hdd".

Gibt es eine Möglichkeit, die Platte noch zu retten - oder ist die nun
ein Fall für's Recycling?


Viele Grüße,

-----------------
Eberhard Spittler
[ http://www.ebsp.de/ ]

Dirk Marburg

unread,
Jan 8, 2002, 1:35:06 PM1/8/02
to
Eberhard Spittler wrote:

Hallo Eberhard,
vemultich bleibt dir nur der Weg zu deinem Händler, der eine
Lowlevel-Formatierung durchführen kann. Vor einem erneuten Einbau würde ich
eventuell das BIOS updaten.

Gruß

Dirk

Gerhard Kowar

unread,
Jan 8, 2002, 1:46:26 PM1/8/02
to

Eberhard Spittler schrieb:
>

>
> Gibt es eine Möglichkeit, die Platte noch zu retten - oder ist die nun
> ein Fall für's Recycling?

dd if=/dev/zero of=/dev/hdd count=1024
löscht partitiontab. etc.
dann nochmal fdisk probieren

Bernd Mayer

unread,
Jan 8, 2002, 2:59:30 PM1/8/02
to
Eberhard Spittler wrote:

[Probleme mit 40 GB-Festplatte/BIOS]

Hallo Eberhard,

von den Festplattenherstellern gibt es im www Diskmanager-images. Damit
erstellt man eine Diskette mit Tools zum Festplattentest,
Partitionierung, Löschen der Festplatte, Sichern der Partitionsdaten
usw..

Sieh mal nach was Dein Hersteller da anbietet und teste die tools.

HTH


Bernd Mayer
--
Linux - more power for less bucks.

Helmut Hullen

unread,
Jan 8, 2002, 1:51:00 PM1/8/02
to
Hallo, Eberhard,

Du (Eberhard.Spittler) meintest am 08.01.02:

> Gibt es eine Moeglichkeit, die Platte noch zu retten - oder ist die
> nun ein Fall fuer's Recycling?

Oft hilft
dd if=/dev/zero of=/dev/hdd count=1000
^oder wo auch immer die Platte ist

Dann ist natuerlich alles weg!

Viele Gruesse!
Helmut

Sven Hartge

unread,
Jan 8, 2002, 3:36:27 PM1/8/02
to
Dirk Marburg <Dirk.M...@t-online.de> wrote:

> vemultich bleibt dir nur der Weg zu deinem Händler, der eine
> Lowlevel-Formatierung durchführen kann.

Urgh.

Heute wird keine Festplatte mehr Lowlevel-Formatiert und die Händler
machen das schon gar nicht.

S!

--
BOFH excuse #205:

Quantum dynamics are affecting the transistors

Joern Abatz

unread,
Jan 8, 2002, 4:15:51 PM1/8/02
to
Eberhard Spittler <Eberhard...@T-online.de> wrote:
> Nun habe ich sie mit Kernelparametern (notlinux hdd=65535,16,63) beim
> Start auf 32 GB gelupft; das ist zwar nicht alles, aber immerhin doppelt
> so viel, wie ich vorher hatte.
> Dann habe ich munter vor mich hin partitioniert und beim Schreiben in
> die Partitionstabelle ("w" von fdisk) gab es die Fehlermeldung, daß auf
> /dev/hdd nicht geschrieben werden könne. Seitdem ist die Platte im
> Eimer. Wenn ich nun "fdisk /dev/hdd" aufrufe, kommt reproduzierbar die
> Meldung "Unable to read /dev/hdd".

Stehen die Parameter 65535,16,63 auf der Platte so drauf. oder hast Du
sie Dir ausgedacht und berechnet? Vielleicht benimmt sich die Platte
wieder wie vorher, wenn Du die Kernelparameter wegläßt und sie im
Bios wieder anmeldest.

Vielleicht hat die Platte einen Jumper "32 GB Clip", und damit
funktioniert sie.

Vielleicht hat der Mainboard-Hersteller ein Bios-Update.

Die Partitionstabelle überschreiben mit
dd if=/dev/zero of=/dev/hdd bs=512 count=1
nochmal partitionieren und nach dem Partitionieren booten
(manche Biosse können die geänderte Partitionstabelle nicht
neu einlesen).

Wenn alles nicht hilft: Vielleicht hat der Plattenhersteller ein Tool
zum Testen und Lowlevel-Formatieren.

Jörn

Eberhard Spittler

unread,
Jan 9, 2002, 2:07:40 AM1/9/02
to
Bernd Mayer schrieb:
>
> Eberhard Spittler wrote:

> von den Festplattenherstellern gibt es im www Diskmanager-images. Damit
> erstellt man eine Diskette mit Tools zum Festplattentest,
> Partitionierung, Löschen der Festplatte, Sichern der Partitionsdaten
> usw..
>

Hallo Bernd,

vielen Dank für den Hinweis. Bei Fujitsu fand ich Tools, konnte damit
aber nichts richtiges Anfangen. Das einzige, was "angeschlagen" hat, war
Umschalten des UDMA-Modus von 100 auf 33. Ich betreibe die Platte aber
ohnehin nur im PIO-Modus.

Aber das Problem hat sich überraschend einfach gelöst - vgl. weitere
Antwort in diesem Faden.

Eberhard Spittler

unread,
Jan 9, 2002, 2:16:07 AM1/9/02
to
Joern Abatz schrieb:

>
>
> Stehen die Parameter 65535,16,63 auf der Platte so drauf. oder hast Du
> sie Dir ausgedacht und berechnet?

Die 65535 Zylinder habe ich mir ausgedacht, weil das die größte
Zylinderzahl ist, die Kernel 2.2.10 kann. Draufstehen tun 16383, womit
es aber nur 8 GB gibt

Die "Lösung" war keine Lösung, aber ziemlich einfach:

Ich habe von einer neueren Linux-CD mit Kernel 2.2.18 gebootet und
darunter war - oh Wunder - die Platte plötzlich wieder ansprechbar. Die
vorher draufgeschriebene Partionstabelle war lesbar und die Platte hatte
mehr als 79000 Zylinder und volle Kapazität.

Damit steht schon mal fest: sie muß nicht auf den Schrott. Wie ich sie
allerdings von 2.2.10 aus anspreche ist mir noch nicht klar. Ein
versuchtes Systemupdate (SuSE 6.2 auf 7.1) ist vor Monaten kläglich
gescheitert. Vieleicht besorge ich mir einen nur geringfügig neueren
Kernel. Zum Aktualisieren habe ich weiter keinen Grund. Der Rechner
(Apache, ht/dig, netatalk, NFS, Samba, Hylafax) läuft stabil wie ein
Uhrwerk und ich brauche keinen neuen Features.

> Die Partitionstabelle überschreiben mit
> dd if=/dev/zero of=/dev/hdd bs=512 count=1
> nochmal partitionieren und nach dem Partitionieren booten
> (manche Biosse können die geänderte Partitionstabelle nicht
> neu einlesen).
>

Vielen Dank an alle, die mir dieses dd-Komando mitgeteilt haben. Ich
schiebe die Info ins Archiv; der nächste Fehler kommt bestimmt - bei
diesen fortwährenden Überschreitungen selbsterrichteter Grenzen und den
dazugehörigen Pionierbrücken.

;-)

Philipp Schulte

unread,
Jan 9, 2002, 3:44:06 AM1/9/02
to
Eberhard Spittler wrote:

> Damit steht schon mal fest: sie muß nicht auf den Schrott. Wie ich sie
> allerdings von 2.2.10 aus anspreche ist mir noch nicht klar. Ein
> versuchtes Systemupdate (SuSE 6.2 auf 7.1) ist vor Monaten kläglich
> gescheitert. Vieleicht besorge ich mir einen nur geringfügig neueren
> Kernel.

Nein, besorg dir 2.2.20 von kernel.org. Dazu bedarf es keines
Suse-Updates, die Sicherheits-Updates für deine Distribution solltest
du natürlich trotzdem installieren.
Phil

Joern Abatz

unread,
Jan 9, 2002, 6:57:04 AM1/9/02
to
Sven Hartge <sh-...@ds9.argh.org> wrote:
>> vemultich bleibt dir nur der Weg zu deinem Händler, der eine
>> Lowlevel-Formatierung durchführen kann.
>
> Heute wird keine Festplatte mehr Lowlevel-Formatiert und die Händler
> machen das schon gar nicht.

Das war lange Zeit vollkommen richtig, aber inzwischen hat sich
die Situation wieder geändert. Mindestens Maxtor und IBM bieten auf
ihren Homepages Diagnose- und Lowlevel-Formatierungstools zum
Runterladen an.

Aus den Texten, die bei IBM dabeistehen, kann man erkennen, daß
sie die Tools deshalb anbieten, weil sie in Reklamationen ertrunken
sind. Sie schreiben, man soll doch - bittebitte - nicht gleich
reklamieren, sondern erstmal das Diagnosetool laufen lassen, und
das sagt einem z.B. unter anderem, ob Oberflächenfehler auf der
Platte sind, die sich durch Lowlevel-Formatierung beheben lassen
oder nicht. Und wenn ja, soll man das auch gleich machen.

Für registrierte Händler bieten sie ein erweitertes Tool an, das z.B.
auch noch feststellt, ob Oberflächenfehler dadurch entstanden sind,
daß eine von den Platten aus der Zentrierung raus ist. Dann ist die
Platte nämlich mal runtergefallen, und dann gibt es keine Gewähr-
leistung mehr.

Jörn

Joern Abatz

unread,
Jan 9, 2002, 6:42:38 AM1/9/02
to
Eberhard Spittler <Eberhard...@T-online.de> wrote:
> Damit steht schon mal fest: sie muß nicht auf den Schrott. Wie ich sie
> allerdings von 2.2.10 aus anspreche ist mir noch nicht klar. Ein
> versuchtes Systemupdate (SuSE 6.2 auf 7.1) ist vor Monaten kläglich
> gescheitert. Vieleicht besorge ich mir einen nur geringfügig neueren
> Kernel. Zum Aktualisieren habe ich weiter keinen Grund. Der Rechner
> (Apache, ht/dig, netatalk, NFS, Samba, Hylafax) läuft stabil wie ein
> Uhrwerk und ich brauche keinen neuen Features.

Wenn Du Dein System möglichst nicht aktualisieren willst, mir ist da
noch was eingefallen. Stichwort "Diskmanager":

Ich hatte mal eine 30 GB Platte in einem Rechner, dessen Bios nur
8 GB ansprechen konnte. Ich hatte sie damals mit Partition Magic
partitioniert und formatiert, und konnte sie dann "einfach so" benutzen.
Und zwar unter Windows und auch unter Linux mit einem 2.0.34 Kernel.

Offenbar hatte Partition Magic einen von diesen "Disk-Managern"
dabei, die in Spur Null installiert werden, und das Bios so ergänzen,
daß auch größere Platten funktionieren. Spur Null ist frei bis auf
Kopf Null/Sektor Null, der den MBR und die Partitionstabelle enthält.

(Eine der Zahlen "Spur", "Kopf", "Sektor" zählt in Wahrheit nicht von
Null, sondern von Eins an, ich glaube, es war "Sektor". Die
CHS-Adressierung ist nicht mehr so gängig.)

Man kann sowohl eine (nicht ganz aktuelle) Version von Partition Magic
als auch diverse Disk-Manager irgendwo zum Runterladen bekommen.

Jörn

Michael Baeuerle

unread,
Jan 9, 2002, 7:13:35 AM1/9/02
to
Joern Abatz wrote:
>
> Sven Hartge <sh-...@ds9.argh.org> wrote:
> >> vemultich bleibt dir nur der Weg zu deinem Händler, der eine
> >> Lowlevel-Formatierung durchführen kann.
> >
> > Heute wird keine Festplatte mehr Lowlevel-Formatiert und die Händler
> > machen das schon gar nicht.
>
> Das war lange Zeit vollkommen richtig, aber inzwischen hat sich
> die Situation wieder geändert. Mindestens Maxtor und IBM bieten auf
> ihren Homepages Diagnose- und Lowlevel-Formatierungstools zum
> Runterladen an.
>

Die aber allesamt nicht mehr das tun (koennen), was man frueher mal
unter "Low Level Format" verstanden hat. Bei IDE beschraenkt sich das
heute wohl auf das Auffuellen der Sektoren mit Initialisierungsmustern
sowie einen Test aller Sektoren und ein Update der Defektliste. Viele
SCSI-Platten sind ausserdem noch in der Lage die Sektoren komplett neu
zu erstellen, wenn sie mehrere Sektorgroessen unterstuetzen.

Heute ist dagegen *keine* Platte mehr in der Lage, ihr magnetisches
Format selbst neu zu schreiben (speziell die Servodaten) - Wenn daran
was beschaedigt ist -> RMA oder Tonne.


Micha

Sven Hartge

unread,
Jan 9, 2002, 11:00:57 AM1/9/02
to
Joern Abatz <ne...@abatz.de> wrote:
> Sven Hartge <sh-...@ds9.argh.org> wrote:

>>> vemultich bleibt dir nur der Weg zu deinem Händler, der eine
>>> Lowlevel-Formatierung durchführen kann.

>> Heute wird keine Festplatte mehr Lowlevel-Formatiert und die Händler
>> machen das schon gar nicht.

> Das war lange Zeit vollkommen richtig, aber inzwischen hat sich die
> Situation wieder geändert. Mindestens Maxtor und IBM bieten auf ihren
> Homepages Diagnose- und Lowlevel-Formatierungstools zum Runterladen
> an.

Wenn ich mich richtig erinnere, dann _können_ heutige Platten gar nicht
mehr LowLevel-Formatiert werden, da dies heißt, das auch die Servo-Infos
neu geschrieben werden. Heute sind diese aber in die Datenspuren (bzw.
besser gesagt daneben) eingewoben, eine LowLevel-Formatierung würde die
Plattenstruktur zerstören und die Platte wäre Sondermüll.

> Aus den Texten, die bei IBM dabeistehen, kann man erkennen, daß
> sie die Tools deshalb anbieten, weil sie in Reklamationen ertrunken
> sind. Sie schreiben, man soll doch - bittebitte - nicht gleich
> reklamieren, sondern erstmal das Diagnosetool laufen lassen, und
> das sagt einem z.B. unter anderem, ob Oberflächenfehler auf der
> Platte sind, die sich durch Lowlevel-Formatierung beheben lassen
> oder nicht. Und wenn ja, soll man das auch gleich machen.

Was diese Tools machen ist, sie schreiben einen Sektor, prüfen, ob sie
den Sektor wieder lesen können und wenn nicht, dann wird er als defekt
markiert und weiter geht es mit dem nächsten. Das ist aber _keine_
LowLevel-Formatierung, das ist eher mit einer Oberflächeanalyse a la
SCANDISK.EXE zu vergleichen, wenngleich die Tools von IBM/Seagate/usw.
sich nicht um Dateisysteme scheren, sondern gleich von Sektor 0 bis
Sektor XYZ durchgehen. badblocks macht nichts anderes.

S!

--
BOFH excuse #250:

Program load too heavy for processor to lift.

Joern Abatz

unread,
Jan 9, 2002, 2:00:04 PM1/9/02
to
Sven Hartge <sh-...@ds9.argh.org> wrote:
>>> Heute wird keine Festplatte mehr Lowlevel-Formatiert und die
>>> Händler machen das schon gar nicht.
>
>> Mindestens Maxtor und IBM bieten auf ihren
>> Homepages Diagnose- und Lowlevel-Formatierungstools zum
>> Runterladen an.

siehe z.B.
http://www.storage.ibm.com/hdd/support/download.htm#DFT
dort heißt es: "Restores drive fitness ... Erase Bootsector utility ...
Low-level format utility"

> Das ist aber _keine_
> LowLevel-Formatierung

Woher weißt Du das? Kannst Du eine Quelle nennen?
(Bitte eine seriöse Quelle, keine Usenet-Artikel oder PC-Zeitschriften)

Jörn

Sven Hartge

unread,
Jan 9, 2002, 3:56:38 PM1/9/02
to

Dazu muss ich etwas suchen, Geduld bitte. (Gute Grundlagen-Infos wachsen
leider nicht auf Bäumen.)

S!

--
BOFH excuse #76:

Unoptimized hard drive

Joern Abatz

unread,
Jan 9, 2002, 6:40:16 PM1/9/02
to
Sven Hartge <sh-...@ds9.argh.org> wrote:

>> siehe z.B. http://www.storage.ibm.com/hdd/support/download.htm#DFT
>> dort heißt es: "Restores drive fitness ... Erase Bootsector utility
>> ... Low-level format utility"
>>>
>>> Das ist aber _keine_ LowLevel-Formatierung
>
>> Woher weißt Du das? Kannst Du eine Quelle nennen? (Bitte eine
>> seriöse Quelle, keine Usenet-Artikel oder PC-Zeitschriften)
>
> Dazu muss ich etwas suchen, Geduld bitte. (Gute Grundlagen-Infos
> wachsen leider nicht auf Bäumen.)

Ich weiß. Ich will auch gern mitsuchen. Bis jetzt habe ich:

http://www.pcguide.com/ref/hdd/geom/formatUtilities-c.html

Das ist - für mein Gefühl - etwas Ähnliches wie eine "Zeitschrift". Noch
nicht ganz das, was für mich eine "Quelle" ist. Ich kann es nicht anders
erklären als: Der Tonfall des Artikels ist nicht wirklich authentisch. Strahlt
keine echte Kompetenz aus. Da redet jemand, der es nicht selber weiß,
sondern der fremdes Wissen zusammenträgt.

Ja, ok, ich bin mißtrauisch. Und ich weiß auch, warum. Die Geschichte ist
folgende: In den 80ern gab es das Spiel "Leisure Suit Larry in the Land of
the Lounge Lizards" (heute ist das "Larry Eins"). Das wurde damals
raubkopiert wie verrückt. Und irgendwann tauchte ein Gerücht auf: In
den Raubkopien von "Larry" ist ein Virus versteckt.

Einer meiner Freunde erzählte: Bei seinem Bruder hätte es die gesamte
Festplatte gelöscht, während am Ende des Spiels das Feuerwerk zu
sehen war. In mindestens zwei PC-Zeitschriften (die Namen habe ich
leider vergessen) wurde von dem Virus berichtet. Im Computerclub
("A.U.G.E.") erzählte jemand, er hätte mit eigenen Augen gesehen, wie
das Virus bei einem seiner Bekannten die Platte gelöscht habe, sie sei
hinterher tatsächlich völlig leer gewesen.

Vielleicht lag es daran, daß die Geschichte in verschiedenen Versionen
erzählt wurde, vielleicht lag es daran, daß es immer "Bekannte" waren,
die sie erlebt hatten, jedenfalls hatte ich ein komisches Gefühl bei der
Geschichte vom Larry-Virus.

Ich habe mir damals dann einfach mal alle Versionen von Raubkopien
besorgt, die es überhaupt gab. Ich habe einfach alle Leute angebohrt,
die ich kannte. Von Flensburg bis Baden-Württemberg. Es gab letztlich
nur zwei verschiedene Versionen, die sich auch nur in einem einzigen
Byte unterschieden (vermutlich war das ein Kopierfehler, der sich
irgendwann mal eingeschlichen hatte).

Umd es ist mir gelungen, eine Gruppe von ca. 10 Leuten zu einer Art
Party zu überreden, wo wir das Spiel gemeinsam auf mehreren
Rechnern durchgespielt haben. Das Ergebnis war: Es gab überhaupt
kein Virus. Die Freunde, die Bekannten, die Zeitschriften: Alle waren
auf eine "Urban Legend" hereingefallen und hatten sie bereitwillig
kolportiert.

Ich weiß jetzt nicht genau, woher es kommt, aber ich habe bei der
Geschichte von der Low-Level-Formatierung "irgendwie" wieder
dieses komische Gefühl, daß daran irgend etwas nicht stimmt.

Natürlich kann es sein, daß ich mich irre. Es wäre nicht das erste
Mal. Aber ich will es wissen. Ich glaube, wenn die Quelle im Internet
ist, dann finden wir sie auch früher oder später.

Und wenn noch ein paar Leute mitsuchen: So macht Usenet Spaß.

Jörn

Thorsten Lange

unread,
Jan 10, 2002, 4:36:22 AM1/10/02
to
Joern Abatz <ne...@abatz.de> writes:

[...]


> Ich weiß jetzt nicht genau, woher es kommt, aber ich habe bei der
> Geschichte von der Low-Level-Formatierung "irgendwie" wieder
> dieses komische Gefühl, daß daran irgend etwas nicht stimmt.

Man kann heutige Festplatten tatsächlich nicht mehr
Low-Level-Formatieren - und das ist kein Großstadmärchen...

Der Begriff "formatieren" ist dank MS-DOS leider sehr unscharf
geworden, was vor allem daran liegt, dass das DOS-"format" zwei
verschiedene Dinge macht, wenn man z.B. Disketten benutzt: Es
formatiert die Diskette und legt ein Dateisystem an. (Die Überprüfung
des Datenträgers auf defekte Sektoren vernachlässigen wir an dieser
Stelle.)

Beim "echten" formatieren wird das Sektor-Format auf dem Datenträger
aufgebaut, Synchronmarkierungen werden aufgebracht usw. Wenn dieser
Schritt erledigt ist, wird das Dateisystem angelegt, dabei werden ein
(leeres) Wurzelverzeichnis und die nötigen Verwaltungsstrukturen
geschrieben.

Bei unixoiden Betriebssystemen sind diese beiden Aufgaben auch auf
zwei verschiedene Tools verteilt: format (das ist natürlich
hardwarespezifisch, wie z.B. fdformat) und mkfs - aber das sollte hier
in der Gruppe eigentlich bekannt sein. ;-)

Wenn man es mit Festplatten zu tun hat, verhält sich das DOS-format
klammheimlich anders: Es wird nicht mehr formatiert, sondern nur noch
das Dateisystem geschrieben. Für die eigentliche Formatierung kam dann
ein Low-Level-Format-Utility zum Einsatz.

Bei unseren heutigen Festplatten (damit sind praktisch alle Platten
gemeint, die nicht älter als 10 Jahre sind), ist eine
User-Formatierung aber nicht mehr möglich. Das Sektor-Format und vor
allem die Synchronmarkierungen aufzubringen ist bei diesen Platten
ohne zusätzliche Hilfsmittel einfach nicht mehr möglich; dieser
Vorgang wird daher bei der Herstellung der Platte durchgeführt und
danach nicht mehr.

Eine möglicher Grund, warum eine Festplatte eine LL-Formatierung nicht
mehr "aus eigener Kraft" durchführen kann, ist z.B. der geänderte
Antrieb des Kopfkamms. Bei älteren Platten wurde hierfür ein
Steppermotor eingesetzt; die Köpfe können hier nur in Schritten über
die Plattenoberfläche bewegt werden. Mit zunehmender Spurdichte wurde
dieses Art der Steuerung aber unpraktikabel, die Spurlage wird z.B.
durch die Wärmeausdehnung beeinflusst, so dass eine genauere Führung
der Köpfe benötigt wird, die auch eine Nachführung und Feinjustierung
ermöglicht, was ein Steppermotor aber nicht leisten kann. Die Lösung
sind Linearmotoren bzw. Voice-Coil-Antriebe; hier kann die Position
des Kopfes stufenlos gesteuert werden, der damit immer genau über der
Spur liegen. Genau das macht eine Low-Level-Formatierung unmöglich,
denn dabei werden die Spuren erzeugt - aber woher bekommt ein solcher
Antrieb seine Spurführung, wenn noch keine Spuren vorhanden sind?

Die LL-Format-Tools, die man heute bekommt, lassen diesen Teil also
weg; es ist nur noch der Teil übrig, der die Platten auf defekte
Sektoren prüft und ggf. ein Remapping veranlasst.

Wenn ihr Hinweise in der Literatur suchen wollt, dann empfehle ich die
c't aus den Jahrgängen '90 und '91...

Bye,
Thorsten

Eberhard Spittler

unread,
Jan 10, 2002, 9:12:09 AM1/10/02
to
Philipp Schulte schrieb:
>

> Nein, besorg dir 2.2.20 von kernel.org. Dazu bedarf es keines
> Suse-Updates, die Sicherheits-Updates für deine Distribution solltest
> du natürlich trotzdem installieren.

Das werde ich tun. Gestern war ich in der hiesigen Computerladen-Straße
und fand tatsächlich 2 alte SuSE-snapshots von 1999: 6.3 und 6.4.

Nur wollte der Händler vom damaligen Preis von DM 49,- nicht runter. Der
glaubt wohl tatsächlich, er könne die Dinger noch verkaufen. Dann habe
ich daran gedacht, mir zusätzlich eine 30 GB-Platte zu kaufen. Ein
einziger Laden hatte noch eine für 122 €. Das schien mir dann aber auch
zu blöd. Die anderen Läden hatten an IDE-Platten nur 20GB (nicht viel
mehr als meine ausgemusterte 15 GB) und > 40 GB.

Da scheint mir Dein Vorschlag sinnvoller. Und wenn es schief geht, kann
ich immer noch in einen der 2 sauren Äpfel beißen.

Sven Hartge

unread,
Jan 10, 2002, 5:35:32 PM1/10/02
to
[Ich mache mal Xpost && Fup2 in passende Gruppe mit größeren Quote.]

Genau das meinte ich.

Früher war ja a) entweder ein Stepper-Motor drin, oder die Servo-Infos
lagen auf einer separaten Platte vor, so daß die Köpfe auch bei
Verwendung eines VoiceCoils präzise geführt werden konnte.

Heute sind diese Servo-Infos aber in die Spuren selber eingewoben, bzw.
liegen etwas daneben. Wenn der Kopf jetzt beim Lesen stärkere
Servo-Signale empfängt, weiß die Elektronik, das sie sprichwörtlich
"neben der Spur ist". Eine Optimale Spurlage ist dann erreicht, wenn
keine Servo-Informationen empfangen werden.

So zumindest ein mir in Erinnerung gebliebener Artikel der c't. (Ist
noch _so_ lange her, maximal 3 Jahre)

> Die LL-Format-Tools, die man heute bekommt, lassen diesen Teil also
> weg; es ist nur noch der Teil übrig, der die Platten auf defekte
> Sektoren prüft und ggf. ein Remapping veranlasst.

Sprich genau das, was man mit badblocks auch erreichen kann.

S!

--
BOFH excuse #198:

Post-it Note Sludge leaked into the monitor.

Thorsten Lange

unread,
Jan 11, 2002, 3:57:10 AM1/11/02
to
Sven Hartge <sh-...@ds9.argh.org> writes:

> [Ich mache mal Xpost && Fup2 in passende Gruppe mit größeren Quote.]

[Ignoriert, da es jetzt wieder Unix-spezifisch wird :-)]

> > Die LL-Format-Tools, die man heute bekommt, lassen diesen Teil also
> > weg; es ist nur noch der Teil übrig, der die Platten auf defekte
> > Sektoren prüft und ggf. ein Remapping veranlasst.
>
> Sprich genau das, was man mit badblocks auch erreichen kann.

Nicht ganz genau das selbe: badblocks erstellt nur eine Liste der
defekten Sektoren, die von einem darauf folgenden mkfs benutzt werden
kann, damit diese nicht vom Dateisystem verwendet werden.

Wenn die Platte ihr LL-Format (oder das, was davon übrig geblieben
ist) durchführt, kann sie dagegen Reservesektoren einsetzen, sofern
noch welche verfügbar sind. Solange das der Fall ist, verringert sich
die Nettokapazität der Platte nicht.

Bye,
Thorsten

Sven Hartge

unread,
Jan 11, 2002, 9:31:35 AM1/11/02
to
Thorsten Lange <la...@lmr.khm.de> wrote:

> Wenn die Platte ihr LL-Format (oder das, was davon übrig geblieben
> ist) durchführt, kann sie dagegen Reservesektoren einsetzen, sofern
> noch welche verfügbar sind. Solange das der Fall ist, verringert sich
> die Nettokapazität der Platte nicht.

Diese Reserve-Sektoren sollte die Platte aber eigentlich auch im
normalen Betrieb umsetzen.

S!

--
75 Things you don't want to hear from your Sys Admin.
70. We don't support that. We won't support that.

Joern Abatz

unread,
Jan 11, 2002, 3:00:27 PM1/11/02
to
Sven Hartge <sh-...@ds9.argh.org> wrote:
> Diese Reserve-Sektoren sollte die Platte aber eigentlich auch im
> normalen Betrieb umsetzen.

Das meine ich auch. Ich hatte mindestens 4 Fälle von verbrauchter
Reserve durch exzessive Schreibvorgänge immer auf dieselbe Stelle
(die Haupt-Lockdatei eines bekannten Realtime-Börsenprogramms).

Und zwar ohne Scandisk oder sonstiges zwischendurch. Nach einem
bis eineinhalb Jahren erschien bei dieser Datei plötzlich ein
bleibender Oberflächenfehler.

Jörn

Sven Hartge

unread,
Jan 11, 2002, 5:02:37 PM1/11/02
to
Joern Abatz <ne...@abatz.de> wrote:
> Sven Hartge <sh-...@ds9.argh.org> wrote:

>> Diese Reserve-Sektoren sollte die Platte aber eigentlich auch im
>> normalen Betrieb umsetzen.

> Das meine ich auch. Ich hatte mindestens 4 Fälle von verbrauchter
> Reserve durch exzessive Schreibvorgänge immer auf dieselbe Stelle (die
> Haupt-Lockdatei eines bekannten Realtime-Börsenprogramms).

Was haben die denn gelockt? Enten? *scnr*

> Und zwar ohne Scandisk oder sonstiges zwischendurch. Nach einem bis
> eineinhalb Jahren erschien bei dieser Datei plötzlich ein bleibender
> Oberflächenfehler.

Zuzusagen ein Trampelpfad in der Magnetschicht ;)

S!

--
BOFH excuse #150:

Arcserve crashed the server again.

Joern Abatz

unread,
Jan 12, 2002, 6:47:14 AM1/12/02
to
Sven Hartge <sh-...@ds9.argh.org> wrote:
>> Haupt-Lockdatei eines bekannten Realtime-Börsenprogramms).
>
> Was haben die denn gelockt? Enten? *scnr*

Kunden: Erst gelockt, dann abgezockt. Kennt man ja.

> Zuzusagen ein Trampelpfad in der Magnetschicht ;)

Ich habe leider nichts Vernünftiges gefunden zur Alterung von
Datenträgern durch häufiges Ummagnetisieren.

Die laufenden Forschungen zur Alterung von magnetischen
Datenträgern konzentrieren sich offenbar alle auf das Problem
der Alterung von Datenträgern, die einmal aufgezeichnet und
dann lange aufbewahrt werden.

Jörn

Sven Hartge

unread,
Jan 12, 2002, 8:34:59 AM1/12/02
to
Joern Abatz <ne...@abatz.de> wrote:
> Sven Hartge <sh-...@ds9.argh.org> wrote:
>> Zuzusagen ein Trampelpfad in der Magnetschicht ;)

> Ich habe leider nichts Vernünftiges gefunden zur Alterung von
> Datenträgern durch häufiges Ummagnetisieren.

Nun, ich kann mir schon vorstellen, das bei häufigen Zugriffen auf eine
bestimmte Stelle die Chance, dort einen Fehler zu erhalten, größer ist,
als wenn die Zugriffe über die komplette Oberfläche verteilt werden.

S!

--
142 Reasons, Why You Can't Find Your System Administrator
53. They've gone to find some more coffee. Sysadmin has left the building!

M. Buchenrieder

unread,
Jan 13, 2002, 10:29:44 AM1/13/02
to
Thorsten Lange <la...@lmr.khm.de> writes:

>Sven Hartge <sh-...@ds9.argh.org> writes:

[...]

>> Sprich genau das, was man mit badblocks auch erreichen kann.

[...]

>Wenn die Platte ihr LL-Format (oder das, was davon übrig geblieben
>ist) durchführt, kann sie dagegen Reservesektoren einsetzen, sofern
>noch welche verfügbar sind. Solange das der Fall ist, verringert sich
>die Nettokapazität der Platte nicht.

Das tun alle IDE-Platten schin im Normalbetrieb. Eine "LL-Formatierung"
hat damit grundsaetzlich nichts zu tun. Tatsaechlich wird - wie eben
auch bei "badblocks" - lediglich die Liste der defekten Sektoren
aktualisiert.

Michael
--
Michael Buchenrieder * mi...@scrum.greenie.muc.de * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.

Sven Hartge

unread,
Jan 13, 2002, 6:31:25 PM1/13/02
to
M. Buchenrieder <mi...@scrum.muc.de> wrote:
> Thorsten Lange <la...@lmr.khm.de> writes:
>> Sven Hartge <sh-...@ds9.argh.org> writes:

>>> Sprich genau das, was man mit badblocks auch erreichen kann.

>> Wenn die Platte ihr LL-Format (oder das, was davon übrig geblieben


>> ist) durchführt, kann sie dagegen Reservesektoren einsetzen, sofern
>> noch welche verfügbar sind. Solange das der Fall ist, verringert sich
>> die Nettokapazität der Platte nicht.

> Das tun alle IDE-Platten schin im Normalbetrieb. Eine
> "LL-Formatierung" hat damit grundsaetzlich nichts zu tun. Tatsaechlich
> wird - wie eben auch bei "badblocks" - lediglich die Liste der
> defekten Sektoren aktualisiert.

Theoretisch müßte auch ein

dd if=/dev/hda of=/dev/null

die Platte dazu veranlassen, schwache Sektoren auf einen anderen Bereich
umzumappen.

S!

--
Fachbegriffe der Informatik - Einfach erklärt
69: WWW
World Wide Windows

Thorsten Lange

unread,
Jan 14, 2002, 4:47:26 AM1/14/02
to
Sven Hartge <sh-...@ds9.argh.org> writes:

> Diese Reserve-Sektoren sollte die Platte aber eigentlich auch im
> normalen Betrieb umsetzen.

Im Prinzip macht sie das. Wenn sie mehrere Leseversuche für einen
Sektor benötigt und auf die ECCs zurückgreifen muss, dann wird nach
einem erfolgreichen Lesevorgang in einen Reservesektor umkopiert.

Aber wie sieht es aus, wenn die Platte den Sektor nicht mehr lesen
kann? In diesem Fall darf sie auf keinen Fall mitten im Betrieb
remappen und anschließend so tun, als sei nichts gewesen. Einen derart
zerstörten Sektor wird man wahrscheinlich nur wieder los, wenn man ein
"LL"-Format anstößt. Das wäre so etwas wie eine Reinitialisierung der
Platte, bei der sie auch solche Sektoren verlegen darf.

Bye,
Thorsten

Thorsten Lange

unread,
Jan 14, 2002, 4:42:26 AM1/14/02
to
mi...@scrum.muc.de (M. Buchenrieder) writes:

[Remapping von defekten Sektoren]


> Das tun alle IDE-Platten schin im Normalbetrieb. Eine "LL-Formatierung"
> hat damit grundsaetzlich nichts zu tun. Tatsaechlich wird - wie eben
> auch bei "badblocks" - lediglich die Liste der defekten Sektoren
> aktualisiert.

Eben nicht. badblocks erzeugt eine Liste von defekten Sektoren, die
vom Dateisystem gehandhabt wird. Im Gegensatz dazu ist das Remapping
der Platte für das Betriebssystem unsichtbar.

Bye,
Thorsten

Michael Baeuerle

unread,
Jan 14, 2002, 6:43:07 AM1/14/02
to
Thorsten Lange wrote:
>
> Aber wie sieht es aus, wenn die Platte den Sektor nicht mehr lesen
> kann? In diesem Fall darf sie auf keinen Fall mitten im Betrieb
> remappen und anschließend so tun, als sei nichts gewesen. Einen derart
> zerstörten Sektor wird man wahrscheinlich nur wieder los, wenn man ein
> "LL"-Format anstößt. Das wäre so etwas wie eine Reinitialisierung der
> Platte, bei der sie auch solche Sektoren verlegen darf.
>

Ueblicherweise reicht das schreiben auf einen defekten Sektor um die
Platte dazu zu veranlassen, diesen zu remappen - da dabei ja keine Daten
verloren gehen. Bei SCSI Platten kann man das auto-remapping fuer lesen
und schreiben separat ein- und ausschalten.


Micha

M. Buchenrieder

unread,
Jan 14, 2002, 9:05:46 AM1/14/02
to
Thorsten Lange <la...@lmr.khm.de> writes:

>mi...@scrum.muc.de (M. Buchenrieder) writes:

Das "remapping" ist zwar transparent, nutzt Dir nur dann nichts mehr,
wenn "badblocks" oder aehnliche Tools bereits fehlerhafte Sektoren
finden - denn dann ist die Platte hin. LL-Formatierug hin- oder her -
eine zeitgenoessische IDE-Platte mit als defekt konstatierten Sektoren
ist ein Fall fuer den Sondermuell. Vielleicht nicht heute, vielleicht nicht
morgen, aber ganz sicher in absehbarer Zukunft.

Sven Hartge

unread,
Jan 14, 2002, 2:29:09 PM1/14/02
to
Thorsten Lange <la...@lmr.khm.de> wrote:
> Sven Hartge <sh-...@ds9.argh.org> writes:

>> Diese Reserve-Sektoren sollte die Platte aber eigentlich auch im
>> normalen Betrieb umsetzen.

> Im Prinzip macht sie das. Wenn sie mehrere Leseversuche für einen
> Sektor benötigt und auf die ECCs zurückgreifen muss, dann wird nach
> einem erfolgreichen Lesevorgang in einen Reservesektor umkopiert.

Ja.

> Aber wie sieht es aus, wenn die Platte den Sektor nicht mehr lesen
> kann? In diesem Fall darf sie auf keinen Fall mitten im Betrieb
> remappen und anschließend so tun, als sei nichts gewesen.

Sie wird einen Defekt nach aussen Melden und den Sektor als Defekt in
ihrer internen Liste markieren. Bei SCSI-Platten kann man dies einfach
auslesen, bei IDE fällt mir da leider nichts passendes ein.

> Einen derart zerstörten Sektor wird man wahrscheinlich nur wieder los,
> wenn man ein "LL"-Format anstößt. Das wäre so etwas wie eine
> Reinitialisierung der Platte, bei der sie auch solche Sektoren
> verlegen darf.

Der Sektor wird dann nicht verlegt, er wird einfach als kaputt markiert,
und fertig. Das geht auch im Betrieb, wie ich letzte Woche Mittwoch
erfahren durfte.

S!

--
Letzte Worte eines Löwenwärters: Der is net hungrig!

0 new messages