Discussion:
Wie entstehen Festplattenfehler?
(zu alt für eine Antwort)
Georges Heinesch
2008-04-18 17:07:07 UTC
Permalink
Hallo.

Wenn man 'mal einen Plattencrash hatte der Datenverlust mit sich
brachte, dann macht man sich seine Gedanken wie Fehler entstehen.

Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.

Wie ist das möglich?

Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-19 03:04:10 UTC
Permalink
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-19 06:37:48 UTC
Permalink
Post by Richard W. Könning
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
"read after write" wäre eine Möglichkeit.

Aus deiner Antwort entnehme ich, dass die Platten einfach nur schreiben
und keine Kontrolle besteht ob die Daten korrekt beschrieben wurden.

Angenommen, die Platte schreibt auf einen defekten Sektor. Wird dies
erst beim Lesen erkannt?

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-19 10:52:11 UTC
Permalink
Guten Tag
Post by Georges Heinesch
Post by Richard W. Könning
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
"read after write" wäre eine Möglichkeit.
1. Wenn Du die HDD erheblich langsamer haben willst, kannst Du das per
Software realisieren.
2. Wenn Du PGP Signaturen erzeugt hast, dann starte ein Verify doch
selber nach dem Kopieren.

Ich lege von meinen Quelldateien CRC32-Checksummen an, kopiere dann
von Quelle zum Ziel und lasse dann spaeter einfach Original mit Ziel
binaer vergleichen (Clonespy) und wenn die identisch sind, werden
durch das Programm die Quellen automatisch in ein Trash-verzeichnis
verschoben. Das loesche ich dann ab und zu manuell.
So sind Schreibfehler nach einem Durchlauf schnell zu bemerken, weil
die Quelldateien stehen bleiben. Dann kann ich anhand der CRC
Checksummen immer sehen, wo sich etwas veraendert hat.
Post by Georges Heinesch
Aus deiner Antwort entnehme ich, dass die Platten einfach nur schreiben
und keine Kontrolle besteht ob die Daten korrekt beschrieben wurden.
Zumindest nicht in dem Umfang, den Du Dir wuenschst. Das haengt zu
einem grossen Teil davon ab, dass die User hohe Geschwindigkeit
wuenschen und per verwendeter Software ein verify selber anstossen
koennen.
Post by Georges Heinesch
Angenommen, die Platte schreibt auf einen defekten Sektor. Wird dies
erst beim Lesen erkannt?
Es wird beim schreiben erkannt.
Es ist nicht so, dass eien HDD stumpf nur schreibt und gar nichts
kontrolliert, aber inhaltliche Kontrolle der geschriebenen Daten
findet nicht in dem Umfang statt, den Du Dir wuenschst.
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141Kbyte <155KByte geloescht.
Georges Heinesch
2008-04-20 06:08:19 UTC
Permalink
Hallo.
Post by Shinji Ikari
Post by Georges Heinesch
Post by Richard W. Könning
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
"read after write" wäre eine Möglichkeit.
1. Wenn Du die HDD erheblich langsamer haben willst, kannst Du das per
Software realisieren.
Also kein "read after write". Ok!
Post by Shinji Ikari
2. Wenn Du PGP Signaturen erzeugt hast, dann starte ein Verify doch
selber nach dem Kopieren.
Ich lege von meinen Quelldateien CRC32-Checksummen an, kopiere dann
von Quelle zum Ziel und lasse dann spaeter einfach Original mit Ziel
binaer vergleichen (Clonespy) und wenn die identisch sind, werden
durch das Programm die Quellen automatisch in ein Trash-verzeichnis
verschoben. Das loesche ich dann ab und zu manuell.
So sind Schreibfehler nach einem Durchlauf schnell zu bemerken, weil
die Quelldateien stehen bleiben. Dann kann ich anhand der CRC
Checksummen immer sehen, wo sich etwas veraendert hat.
Das ist genau das was ich will. Wen man weiß wie eine Festplatte
funktioniert, dann weiß man auch was man dagegen machen soll. genau
darum geht es mir hier in diesem Thread.
Post by Shinji Ikari
Post by Georges Heinesch
Angenommen, die Platte schreibt auf einen defekten Sektor. Wird dies
erst beim Lesen erkannt?
Es wird beim schreiben erkannt.
Es ist nicht so, dass eien HDD stumpf nur schreibt und gar nichts
kontrolliert, aber inhaltliche Kontrolle der geschriebenen Daten
findet nicht in dem Umfang statt, den Du Dir wuenschst.
Das musst du mir jetzt genauer erklären. Es findet keine inhaltliche
Kontrolle der Daten statt (das wäre "mein" read after write), aber
trotzdem merkt die HDD beim Schreiben dass ein fehler aufgetreten ist.
Wie geht das denn?

Gruß,
--
Georges Heinesch
Rupert Haselbeck
2008-04-20 06:33:13 UTC
Permalink
Post by Georges Heinesch
Das musst du mir jetzt genauer erklären. Es findet keine inhaltliche
Kontrolle der Daten statt (das wäre "mein" read after write), aber
trotzdem merkt die HDD beim Schreiben dass ein fehler aufgetreten ist.
Wie geht das denn?
Die Platte kann nur feststellen, ob das, was sie geschrieben hat, mit
dem übereinstimmt, was in ihrem Schreibpuffer steht. Damit ist aber nur
ein kleiner Teil der möglichen Fehler abzufangen, weil die bereits
vorher möglicherweise aufgetretenen Verfälschungen z.B. durch
RAM-Fehler oder Fehler im Datenpfad vom Hauptspeicher zur Platte (z.B.
durch defekte oder zu lange Kabel) damit natürlich nicht entdeckt
werden können

MfG
Rupert
Georges Heinesch
2008-04-20 07:34:40 UTC
Permalink
Post by Rupert Haselbeck
Post by Georges Heinesch
Das musst du mir jetzt genauer erklären. Es findet keine inhaltliche
Kontrolle der Daten statt (das wäre "mein" read after write), aber
trotzdem merkt die HDD beim Schreiben dass ein fehler aufgetreten ist.
Wie geht das denn?
Die Platte kann nur feststellen, ob das, was sie geschrieben hat, mit
dem übereinstimmt, was in ihrem Schreibpuffer steht. Damit ist aber nur
ein kleiner Teil der möglichen Fehler abzufangen, weil die bereits
vorher möglicherweise aufgetretenen Verfälschungen z.B. durch
RAM-Fehler oder Fehler im Datenpfad vom Hauptspeicher zur Platte (z.B.
durch defekte oder zu lange Kabel) damit natürlich nicht entdeckt
werden können
Wie bereits in einem anderen Artikel geschrieben. Eleminieren wir die
Fehler der Kabel, RAM ... und beschränken wir uns auf HDD Cache - HDD
Magnetscheiben. Findet hier irgend eine Kontrolle statt of die Daten
zwischen HDD Cache und HDD Magnetscheiben konsistent sind?

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-20 23:23:15 UTC
Permalink
Post by Georges Heinesch
Post by Rupert Haselbeck
Die Platte kann nur feststellen, ob das, was sie geschrieben hat, mit
dem übereinstimmt, was in ihrem Schreibpuffer steht. Damit ist aber nur
ein kleiner Teil der möglichen Fehler abzufangen, weil die bereits
vorher möglicherweise aufgetretenen Verfälschungen z.B. durch
RAM-Fehler oder Fehler im Datenpfad vom Hauptspeicher zur Platte (z.B.
durch defekte oder zu lange Kabel) damit natürlich nicht entdeckt
werden können
Wie bereits in einem anderen Artikel geschrieben. Eleminieren wir die
Fehler der Kabel, RAM ... und beschränken wir uns auf HDD Cache - HDD
Magnetscheiben. Findet hier irgend eine Kontrolle statt of die Daten
zwischen HDD Cache und HDD Magnetscheiben konsistent sind?
Das kommt darauf an. Wenn Du eine Platte verwendest, die ein Schreiben
mit Prüflesen beherrscht (zumindestens bei SCSI-Platten ist dies
grundsätzlich vorgesehen, ich habe nicht nachgeschaut, ob es dort ein
Pflichtkommando ist) und Du Deinem Betriebssystem beibringst, dieses
Prüflesen zu aktivieren, dann ja, andernfalls eher nein.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Michael Baeuerle
2008-04-21 07:21:03 UTC
Permalink
Post by Richard W. Könning
Post by Georges Heinesch
Wie bereits in einem anderen Artikel geschrieben. Eleminieren wir die
Fehler der Kabel, RAM ... und beschränken wir uns auf HDD Cache - HDD
Magnetscheiben. Findet hier irgend eine Kontrolle statt of die Daten
zwischen HDD Cache und HDD Magnetscheiben konsistent sind?
Das kommt darauf an. Wenn Du eine Platte verwendest, die ein Schreiben
mit Prüflesen beherrscht (zumindestens bei SCSI-Platten ist dies
grundsätzlich vorgesehen, ich habe nicht nachgeschaut, ob es dort ein
Pflichtkommando ist)
Du meinst vermutlich den WRITE AND VERIFY Befehl, der ist kein
Pflichtkommando.
Post by Richard W. Könning
und Du Deinem Betriebssystem beibringst, dieses
Prüflesen zu aktivieren, dann ja, andernfalls eher nein.
Das muss man aber auch nicht zwangsweise per Befehl anfordern, meine
SCSI-MOs machen z.B. auch Verify wenn man sie ganz normal mit WRITE
anspricht. Was bei WRITE genau passiert ist letztlich dem Autor der
Firmware ueberlassen.

Prinzipiell waere "read after write" bei modernen Platten wohl denkbar,
da sie AFAIK 2 Koepfe pro Oberflaeche haben. So in der Art:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/20/11569/00538627.pdf?temp=x
Schreiben tut man da immer noch mit einem induktiven Kopf. Ich habe aber
meine Zweifel ob der GMR-Kopf lesen kann waehrend _gleichzeitig_ der
induktive Kopf schreibt ... das ganze muss ja kompakt und leicht sein,
nicht so eine Konstruktion wie bei Tapes. Letztlich wird es IMHO auch
wieder auf eine zusaetzliche Umdrehung hinauslaufen. Ist das der Fall
kann man es einfach rausmessen: Ist die Platte beim Schreiben aehnlich
schnell wie beim Lesen hat sie kein Verify gemacht.


Micha
Richard W. Könning
2008-04-21 19:36:30 UTC
Permalink
Post by Michael Baeuerle
Post by Richard W. Könning
Das kommt darauf an. Wenn Du eine Platte verwendest, die ein Schreiben
mit Prüflesen beherrscht (zumindestens bei SCSI-Platten ist dies
grundsätzlich vorgesehen, ich habe nicht nachgeschaut, ob es dort ein
Pflichtkommando ist)
Du meinst vermutlich den WRITE AND VERIFY Befehl, der ist kein
Pflichtkommando.
Ja. Ein Blick in die Manuale einiger älterer IBM-SCSI-Platten zeigt
allerdings, daß die diese Kommandos (im Gegensatz zu manch anderen
optionalen Kommandos) wohl doch recht häufig implementiert werden.
Post by Michael Baeuerle
Post by Richard W. Könning
und Du Deinem Betriebssystem beibringst, dieses
Prüflesen zu aktivieren, dann ja, andernfalls eher nein.
Das muss man aber auch nicht zwangsweise per Befehl anfordern, meine
SCSI-MOs machen z.B. auch Verify wenn man sie ganz normal mit WRITE
anspricht. Was bei WRITE genau passiert ist letztlich dem Autor der
Firmware ueberlassen.
Wobei MO-Laufwerke schon eine deutlich andere Geräteklasse als
Festplatten sind, üblicherweise werden sie eher für Backup- oder
Archivierungszwecke verwendet, d.h. Datensicherheit ist im
Zweifelsfall wesentlich wichtiger als Performance. Bei meinem
MO-Laufwerk kann man iirc mit einem Jumper einstellen, ob ein
impliziter Verify gemacht werden soll oder nicht.
Post by Michael Baeuerle
Prinzipiell waere "read after write" bei modernen Platten wohl denkbar,
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/20/11569/00538627.pdf?temp=x
Schreiben tut man da immer noch mit einem induktiven Kopf. Ich habe aber
meine Zweifel ob der GMR-Kopf lesen kann waehrend _gleichzeitig_ der
induktive Kopf schreibt ... das ganze muss ja kompakt und leicht sein,
nicht so eine Konstruktion wie bei Tapes. Letztlich wird es IMHO auch
Das Problem dürfte imho die relative Anordnung von Schreib- und
Lesekopf im Zusammenhang mit der nicht-radialen Bewegung des
Kopfträgers sein; selbst wenn auf einem bestimmten Zylinder die beiden
Köpfe sich genau auf der gleichen Spur befinden, wird dies bei
Zylindern weiter außen oder innen nicht der Fall sein.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Michael Baeuerle
2008-04-22 06:35:39 UTC
Permalink
Post by Richard W. Könning
Post by Michael Baeuerle
Post by Richard W. Könning
Das kommt darauf an. Wenn Du eine Platte verwendest, die ein Schreiben
mit Prüflesen beherrscht (zumindestens bei SCSI-Platten ist dies
grundsätzlich vorgesehen, ich habe nicht nachgeschaut, ob es dort ein
Pflichtkommando ist)
Du meinst vermutlich den WRITE AND VERIFY Befehl, der ist kein
Pflichtkommando.
Ja. Ein Blick in die Manuale einiger älterer IBM-SCSI-Platten zeigt
allerdings, daß die diese Kommandos (im Gegensatz zu manch anderen
optionalen Kommandos) wohl doch recht häufig implementiert werden.
Ack. Die Seagate Cheetahs scheinen ihn auch alle implementiert zu haben
(geschaut bei der 9LP, 10K7 und 15K4), die uralte Hawk 2LP unterstuetzt
ihn ebenfalls. Wer bietet eine SCSI Platte die ihn nicht unterstuetzt?
;-)
Post by Richard W. Könning
Post by Michael Baeuerle
Post by Richard W. Könning
und Du Deinem Betriebssystem beibringst, dieses
Prüflesen zu aktivieren, dann ja, andernfalls eher nein.
Das muss man aber auch nicht zwangsweise per Befehl anfordern, meine
SCSI-MOs machen z.B. auch Verify wenn man sie ganz normal mit WRITE
anspricht. Was bei WRITE genau passiert ist letztlich dem Autor der
Firmware ueberlassen.
Wobei MO-Laufwerke schon eine deutlich andere Geräteklasse als
Festplatten sind, üblicherweise werden sie eher für Backup- oder
Archivierungszwecke verwendet, d.h. Datensicherheit ist im
Zweifelsfall wesentlich wichtiger als Performance.
Ich wollte nur darauf hinweisen, dass es prinzipiell auch ohne spezielle
Befehle moeglich ist. Ich wuesste jetzt aber keinen Grund warum es nicht
auch bei einer Festplatte per Jumper einstellbar sein koennte (mit
default auf "Off"). Dann koennte der User entscheiden was er haben will
...
Post by Richard W. Könning
Bei meinem
MO-Laufwerk kann man iirc mit einem Jumper einstellen, ob ein
impliziter Verify gemacht werden soll oder nicht.
Ja, ist bei meinem Fujitsu M2513A6 auch so.
Post by Richard W. Könning
Post by Michael Baeuerle
Prinzipiell waere "read after write" bei modernen Platten wohl denkbar,
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/20/11569/00538627.pdf?temp=x
Schreiben tut man da immer noch mit einem induktiven Kopf. Ich habe aber
meine Zweifel ob der GMR-Kopf lesen kann waehrend _gleichzeitig_ der
induktive Kopf schreibt ... das ganze muss ja kompakt und leicht sein,
nicht so eine Konstruktion wie bei Tapes. Letztlich wird es IMHO auch
Das Problem dürfte imho die relative Anordnung von Schreib- und
Lesekopf im Zusammenhang mit der nicht-radialen Bewegung des
Kopfträgers sein; selbst wenn auf einem bestimmten Zylinder die beiden
Köpfe sich genau auf der gleichen Spur befinden, wird dies bei
Zylindern weiter außen oder innen nicht der Fall sein.
Hmm, daran hatte ich gar nicht gedacht. Das Problem besteht im normalen
Betrieb aber eigentlich auch: Irgendwie muessen ja die Servodaten
gelesen werden um die Spur zu treffen und nicht wieder zu verlieren.
Wenn man unterstellt, dass das auch mit dem Lese(GMR)-Kopf passiert -
was anderes wie "embedded servo" gibts ja seit Jahren nicht mehr - dann
hat man da doch theoretisch die gleichen Probleme. Sowohl das von mir
genannte als auch dein Winkelproblem.

Ideen wie das geloest wird?


Micha
Richard W. Könning
2008-04-22 23:33:39 UTC
Permalink
Post by Michael Baeuerle
Post by Richard W. Könning
Wobei MO-Laufwerke schon eine deutlich andere Geräteklasse als
Festplatten sind, üblicherweise werden sie eher für Backup- oder
Archivierungszwecke verwendet, d.h. Datensicherheit ist im
Zweifelsfall wesentlich wichtiger als Performance.
Ich wollte nur darauf hinweisen, dass es prinzipiell auch ohne spezielle
Befehle moeglich ist. Ich wuesste jetzt aber keinen Grund warum es nicht
auch bei einer Festplatte per Jumper einstellbar sein koennte (mit
default auf "Off"). Dann koennte der User entscheiden was er haben will
...
Vermutlich eine Frage der Nachfrage. Die RAID0-Kundschaft wird man
damit sicherlich nicht gewinnen.
Post by Michael Baeuerle
Post by Richard W. Könning
Bei meinem
MO-Laufwerk kann man iirc mit einem Jumper einstellen, ob ein
impliziter Verify gemacht werden soll oder nicht.
Ja, ist bei meinem Fujitsu M2513A6 auch so.
Hier ist ein M2513E ;-).
Post by Michael Baeuerle
Post by Richard W. Könning
Das Problem dürfte imho die relative Anordnung von Schreib- und
Lesekopf im Zusammenhang mit der nicht-radialen Bewegung des
Kopfträgers sein; selbst wenn auf einem bestimmten Zylinder die beiden
Köpfe sich genau auf der gleichen Spur befinden, wird dies bei
Zylindern weiter außen oder innen nicht der Fall sein.
Hmm, daran hatte ich gar nicht gedacht. Das Problem besteht im normalen
Betrieb aber eigentlich auch: Irgendwie muessen ja die Servodaten
gelesen werden um die Spur zu treffen und nicht wieder zu verlieren.
Wenn man unterstellt, dass das auch mit dem Lese(GMR)-Kopf passiert -
was anderes wie "embedded servo" gibts ja seit Jahren nicht mehr - dann
hat man da doch theoretisch die gleichen Probleme. Sowohl das von mir
genannte als auch dein Winkelproblem.
Ideen wie das geloest wird?
Laut (was für ein Monster-Link)

http://scp.s-scptuj.mb.edus.si/~murkos/Teorija%20in%20vaje/RSM/techref%20-%20%20HW%20za%20PCje%20-%20film%20Modherboard,%20IDE,Modem.BIOS,opti%E8ni%20diski%20-%20CD%20ob%20knjigi%20OPRAVKA%20RA%C8%20MRE%8EA/Chapter10.pdf

Seite 588 (Seite 20 innerhalb der PDF-Datei) wird das Problem wohl gar
nicht gelöst, sondern durch die Begrenzung des Spurbereichs nur
hinreichend begrenzt. Daraus folgt natürlich, daß mein Einwand gegen
die "Hinterbandkontrolle" nicht zieht.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-23 09:07:51 UTC
Permalink
...
Ist alles sehr interessant (wirklich!), hilft mir aber nicht sonderlich
weiter ... ;)

Ich habe SATA2 Festplatten an einem Areca ARC-1210 Raid hängen. Ich sehr
jetzt 2 Möglichkeiten das read-after-write zu benutzen.

1. Firmware Einstellung der Platte. Ist das möglich?
2. OS (WinXP) Einstellung. Geht das? Wenn ja, wie?

Performance ist untergeordnet.

Vielen Dank.

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-23 20:59:29 UTC
Permalink
Guten Tag
Post by Georges Heinesch
Ich habe SATA2 Festplatten an einem Areca ARC-1210 Raid hängen. Ich sehr
jetzt 2 Möglichkeiten das read-after-write zu benutzen.
1. Firmware Einstellung der Platte. Ist das möglich?
Theoretisch waere es moeglich. In der Praxis ist das nicht
implementiert.
ATA = billig, schnell.
Billig, schnell und sicher sind die Eckpunkte in einem
gleichschenkeligen Dreieck.
In der Regel muss man seinee Wunschvorstellung dazwischen suchen.
Alles drei mit maximaler Auspraegung ist nicht drin.
Post by Georges Heinesch
2. OS (WinXP) Einstellung. Geht das? Wenn ja, wie?
Kenne ich dabei nicht.
Post by Georges Heinesch
Performance ist untergeordnet.
Dann kopiere/verschiebe mit Tools, die direkt nach dem schreiben der
Datei diese auch binaer noch einmal mit dem Original vergleichen.
(Beispielsweise: Totalcommander Befehle/Verzeichnisse
synchronisieren/vergleichen [x] nach Inhalt)
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141kByte <155kByte geloescht.
Rainer Zocholl
2008-04-20 15:18:00 UTC
Permalink
Post by Rupert Haselbeck
Post by Georges Heinesch
Das musst du mir jetzt genauer erklären. Es findet keine inhaltliche
Kontrolle der Daten statt (das wäre "mein" read after write), aber
trotzdem merkt die HDD beim Schreiben dass ein fehler aufgetreten
ist. Wie geht das denn?
Die Platte kann nur feststellen, ob das, was sie geschrieben hat, mit
dem übereinstimmt, was in ihrem Schreibpuffer steht.
Die Plattenelektronik schreibt rel. umfangereiche CRC und Redundanz
werte hinter/vor jeden Sektor.

Sie kann und muss also jederhzeit feststellen ob der Schreib/lesevorgang
OK war. Sieht man mal von extremsten Sonderfällen ab in denen die Fehler
nicht durch den CRC erfasst werden. (Oder nur der CRC-Bereich kaputt ist).



Rainer
--
Transparency International definiert Korruption als
Missbrauch von anvertrauter Macht zum privaten Nutzen oder Vorteil. [...]
Corruption is operationally defined as the misuse of entrusted power for
private gain. [...]
Richard W. Könning
2008-04-20 23:25:26 UTC
Permalink
Post by Rainer Zocholl
Post by Rupert Haselbeck
Die Platte kann nur feststellen, ob das, was sie geschrieben hat, mit
dem übereinstimmt, was in ihrem Schreibpuffer steht.
Die Plattenelektronik schreibt rel. umfangereiche CRC und Redundanz
werte hinter/vor jeden Sektor.
Sie kann und muss also jederhzeit feststellen ob der Schreib/lesevorgang
OK war. Sieht man mal von extremsten Sonderfällen ab in denen die Fehler
nicht durch den CRC erfasst werden. (Oder nur der CRC-Bereich kaputt ist).
Ob das, was vermeintlich geschrieben worden ist, wirklich auf der
Platte gelandet ist, kann erst beim Lesen festgestellt werden.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-23 09:09:38 UTC
Permalink
Post by Richard W. Könning
...
Post by Rainer Zocholl
Sie kann und muss also jederhzeit feststellen ob der Schreib/lesevorgang
OK war. Sieht man mal von extremsten Sonderfällen ab in denen die Fehler
nicht durch den CRC erfasst werden. (Oder nur der CRC-Bereich kaputt ist).
Ob das, was vermeintlich geschrieben worden ist, wirklich auf der
Platte gelandet ist, kann erst beim Lesen festgestellt werden.
Genau das ist mein Punkt! Das Schreiben betrifft auch die CRC/ECC Daten.
Die können ebenso falsch sein wie die Daten selbst, was eben erst nach
einem Prüflesen entdeckt wird.

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-19 20:49:25 UTC
Permalink
Post by Georges Heinesch
Post by Richard W. Könning
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
"read after write" wäre eine Möglichkeit.
Was ist der Unterschied zwischen "read" und "Lesen" (außer daß das
eine Wort aus dem Englischen und das andere aus dem Deutschen stammt)?
Post by Georges Heinesch
Aus deiner Antwort entnehme ich, dass die Platten einfach nur schreiben
und keine Kontrolle besteht ob die Daten korrekt beschrieben wurden.
Angenommen, die Platte schreibt auf einen defekten Sektor. Wird dies
erst beim Lesen erkannt?
Eine Platte kann nur Schreiben und Lesen, wenn sie beim Schreiben
nicht irgendwelche Probleme mit der Spurverfolgung (wie immer die
realisiert sein mag) feststellt, dann kann sie Probleme erst beim
Lesen feststellen (wann immer das Lesen durchgeführt wird). Auch ein
Prüflesen (neudeutsch: "read after write") ist insbesondere eins:
Lesen.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-20 06:13:35 UTC
Permalink
Post by Richard W. Könning
Post by Georges Heinesch
Post by Richard W. Könning
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt festzustellen?
Wie soll sie das beim Schreiben bemerken? (Von Ausnahmefällen wie
Probleme bei der Spurverfolgung abgesehen)
"read after write" wäre eine Möglichkeit.
Was ist der Unterschied zwischen "read" und "Lesen" (außer daß das
eine Wort aus dem Englischen und das andere aus dem Deutschen stammt)?
Ich weiß nicht auf was du hinweisen willst?!
Post by Richard W. Könning
Post by Georges Heinesch
Aus deiner Antwort entnehme ich, dass die Platten einfach nur schreiben
und keine Kontrolle besteht ob die Daten korrekt beschrieben wurden.
Angenommen, die Platte schreibt auf einen defekten Sektor. Wird dies
erst beim Lesen erkannt?
Eine Platte kann nur Schreiben und Lesen, wenn sie beim Schreiben
nicht irgendwelche Probleme mit der Spurverfolgung (wie immer die
realisiert sein mag) feststellt, dann kann sie Probleme erst beim
Lesen feststellen (wann immer das Lesen durchgeführt wird). Auch ein
Lesen.
Beim Schreiben können mehrere Dinge schief laufen. Das Triviale ist das
die Daten inhaltlich falsch geschrieben werden. Diese Kontrolle
(Prüflesen) findet also nicht statt. Weiterhin gibt es dann noich die
Spurverfolgung. Diese wird vom HDD beim Schreiben kontrolliert, wobei
Fehler entdeckt werden.

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-20 23:15:35 UTC
Permalink
Post by Georges Heinesch
Post by Richard W. Könning
Eine Platte kann nur Schreiben und Lesen, wenn sie beim Schreiben
nicht irgendwelche Probleme mit der Spurverfolgung (wie immer die
realisiert sein mag) feststellt, dann kann sie Probleme erst beim
Lesen feststellen (wann immer das Lesen durchgeführt wird). Auch ein
Lesen.
Beim Schreiben können mehrere Dinge schief laufen. Das Triviale ist das
die Daten inhaltlich falsch geschrieben werden. Diese Kontrolle
Wenn Daten falsch geschrieben werden, dann kann das erst beim Lesen
festgestellt werden, wann immer das Lesen stattfindet.
Post by Georges Heinesch
(Prüflesen) findet also nicht statt. Weiterhin gibt es dann noich die
Wird der Fehler beim Prüflesen (so ein solches gemacht wird)
festgestellt, dann wird er beim Lesen festgestellt, da trivialerweise
auch ein Prüflesen ein Lesen ist.
Mit anderen Worten, von Spurfolgeproblemen evtl. abgesehen werden
Fehler *immer* beim Lesen festgestellt (wann immer das Lesen
stattfindet).

Sollte Dir diese Antwort nicht gefallen, dann kann es daran liegen,
daß Deine Frage falsch gestellt ist.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-23 10:43:01 UTC
Permalink
Post by Richard W. Könning
...
Sollte Dir diese Antwort nicht gefallen, dann kann es daran liegen,
daß Deine Frage falsch gestellt ist.
;))

Nee nee ... jede Antwort, die den Gegebenheiten entspricht, gefällt mir.

Gruß,
--
Georges Heinesch
Marcel Müller
2008-04-19 16:36:57 UTC
Permalink
Hallo.
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
Kapputte RAMs.
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben Sektor
defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?
Letzteres.

Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Außerdem hilft es gegen den beschriebenen Fehler meistens doch nichts,
weil nur gegen die bereits falschen Daten im Cache verifiziert wird.
Dass der Platte ein Datenfehler auf dem Medium unbemerkt durch die
Lappen geht, ist extrem unwahrscheinlich. Und noch viel
unwahrscheinlicher ist es, dass dies passiert, bevor etliche andere
bemerkte Lesefehler aufgetreten sind.


Marcel
Georges Heinesch
2008-04-20 07:30:39 UTC
Permalink
Post by Marcel Müller
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
Kapputte RAMs.
Auf dem RAID Controller oder Rechner?
Ist ein Festplattenfehler ausgeschlossen?

Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert) auf
dem Verbund (RAID5).
Post by Marcel Müller
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben
Sektor defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?
Letzteres.
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
Post by Marcel Müller
Außerdem hilft es gegen den beschriebenen Fehler meistens doch nichts,
weil nur gegen die bereits falschen Daten im Cache verifiziert wird.
Es ging mir im ursprünglichen Posting eher darum, ob die Festplatte die
Daten, die die Festplatte erhält ordnungsgemäß physikalisch geschrieben
werden. RAM Fehler (Rechner, RAID Karte, internes HDD Cache) habe ich
außen vor gelassen.

Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
Alle Fehler die nachher auftreten würden, wären zu einem späteren
Zeitpunkt auf irgend eine Weise (?) hinzugeschustert worden.
Post by Marcel Müller
Dass der Platte ein Datenfehler auf dem Medium unbemerkt durch die
Lappen geht, ist extrem unwahrscheinlich.
Gut. Hier steckt ja anscheinend ein Mechanismus dahinter. Die Platte
"bemerkt" Datenfehler. Genau das ist der Punkt. Wie funktioniert der?

Gruß,
--
Georges Heinesch
Marcel Müller
2008-04-20 08:08:55 UTC
Permalink
Hallo,
Post by Georges Heinesch
Post by Marcel Müller
Kapputte RAMs.
Auf dem RAID Controller oder Rechner?
Ist ein Festplattenfehler ausgeschlossen?
Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert) auf
dem Verbund (RAID5).
das kann man nicht sagen. Es könnten sogar die Cache-RAMs der Platten
sein. Nur ist der im PC verbaute Consumer-Ramsch die häufigste Ursache.
Davon sind mittlerweile auch Server zu einem gewissen Grad betroffen,
oder wer hat noch ECC-RAMs?
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
Soweit ich weiß geht beides.
Post by Georges Heinesch
Post by Marcel Müller
Außerdem hilft es gegen den beschriebenen Fehler meistens doch nichts,
weil nur gegen die bereits falschen Daten im Cache verifiziert wird.
Es ging mir im ursprünglichen Posting eher darum, ob die Festplatte die
Daten, die die Festplatte erhält ordnungsgemäß physikalisch geschrieben
werden. RAM Fehler (Rechner, RAID Karte, internes HDD Cache) habe ich
außen vor gelassen.
Dafür hilft das Verify theoretisch. Praktisch ist dieser Fehler abwegig.
Nicht abwegig ist hingegen, dass sich der Block sofort nicht mehr ohne
/erkannten/ Fehler lesen lässt. Auch dagegen hilft Verify.
Nicht helfen tut es daggen bei einem später entstehenden Fehler, wie
thermodynamische Veränderungen der magnetischen Domänen oder Degradation
des Lesekopfes durch Verunreinigung (Flughöhe), Beschädigung
(Head-Crash) oder Alterung (Diffusion) oder auch höheres Rauschen
(Temperatur der Read-Amps).
Sinn ergibt das Verify aber eigentlich nur, wenn nahezu alle Komponenten
einen geeigneten Validierungsschritt durchführen. Also, Parity bei den
Kabeln, ECC beim RAM u.s.w.
Post by Georges Heinesch
Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
Alle Fehler die nachher auftreten würden, wären zu einem späteren
Zeitpunkt auf irgend eine Weise (?) hinzugeschustert worden.
Ja, siehe oben.
Post by Georges Heinesch
Post by Marcel Müller
Dass der Platte ein Datenfehler auf dem Medium unbemerkt durch die
Lappen geht, ist extrem unwahrscheinlich.
Gut. Hier steckt ja anscheinend ein Mechanismus dahinter. Die Platte
"bemerkt" Datenfehler.
Exakt, sonst würde RAID5 überhaupt keinen Sinn ergeben. Es setzt nämlich
nur auf den Fehlern auf die die Platte (kaputter Sektor) ooder der
Controller (Totalausfall) bemerkt.
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.

Man sollte sich von der Vorstellung trennen, das irgendein modernes
Medium überhaupt die ihm anvertraute Information mit hinreichend großer
Wahrscheinlichkeit 1:1 hält, als dass man es für irgendetwas gebrauchen
könnte. Die Fehlerkorrekturen werden ständig gebraucht (bei CD, DVD, HDD
etc.). Ohne Korrektur arbeiten Disketten und analoge Kassetten.

Das ist alles nur Wahrscheinlichkeitsrechnung. Die zugrundeliegende
Auslegung kann man dem Datenblatt der Platte entnehmen. Da trennt sich
schnell die Spreu vom Weizen. In der Profiklasse liegt die Unrecoverable
Error Rate derzeit bei 1 Bit pro 1^15 gelesene Bits. In der Billigklasse
ist es 1 pro 10^14 (also grob 10-mal mehr Fehler). Aufgrund der immer
größer werdenden Platten, wird diese Zahl aber von unten "aufgefressen",
weil man 10^14 Bits eben immer schneller gelesen hat, beispielsweise
eine Terabyteplatte 10-mal Lesen :-o


Marcel
Georges Heinesch
2008-04-20 09:34:03 UTC
Permalink
Hallo.
Post by Marcel Müller
Post by Georges Heinesch
Post by Marcel Müller
Kapputte RAMs.
Auf dem RAID Controller oder Rechner?
Ist ein Festplattenfehler ausgeschlossen?
Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert)
auf dem Verbund (RAID5).
das kann man nicht sagen. Es könnten sogar die Cache-RAMs der Platten
sein. Nur ist der im PC verbaute Consumer-Ramsch die häufigste Ursache.
Davon sind mittlerweile auch Server zu einem gewissen Grad betroffen,
oder wer hat noch ECC-RAMs?
Also wenn man soweit gehen muss um inkonsistente Daten zu erklären, dann
kann man wohl aufhören nach den Ursachen zu suchen. Dann kann es ja
alles sein (Kabel, Stromversorgung, RAM, WLAN Störung, ...). Ich dachte
hisher immer das physikalische Beschreiben sei die Hauptfehlerquelle.
Post by Marcel Müller
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
Soweit ich weiß geht beides.
<staune!> Ich habe Seagate und WD Platten, jedoch habe ich noch bei
keinem der Tools (aktuel, von den hersteller Websites) eine solche
Funktion entdeckt. Auch im Betriebssystem ist mir so etwas noch nicht
begegnet! Bitte um Angaben wo dies zu finden ist ... ;)
Post by Marcel Müller
...
Sinn ergibt das Verify aber eigentlich nur, wenn nahezu alle Komponenten
einen geeigneten Validierungsschritt durchführen. Also, Parity bei den
Kabeln, ECC beim RAM u.s.w.
Kling logisch. Ist das praktisch durchführbar?
Post by Marcel Müller
Post by Georges Heinesch
Gut. Hier steckt ja anscheinend ein Mechanismus dahinter. Die Platte
"bemerkt" Datenfehler.
Exakt, sonst würde RAID5 überhaupt keinen Sinn ergeben. Es setzt nämlich
nur auf den Fehlern auf die die Platte (kaputter Sektor) ooder der
Controller (Totalausfall) bemerkt.
Also nur auf den Fehlern, die die Platte meldet (Kaputter Sektor) oder
der RAID Controller bemerkt (Totalausfall). Ok!
Post by Marcel Müller
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.
Hier muss man aber weiter erklären. ECC mit Rückrechnung der Daten ist
schön und gut, aber wie funktioniert das? Wird die ECC vom HDD
Controller berechnet und mitsamt den Daten auf die HDD geschrieben? In
dem Fall bestände keine Kontrolle ob die Daten richtig geschrieben sind
da alles in einem Rutsch ohne Kontrolle geschrieben wird, ohne zu lesen.
Wenn die HDD jedoch die Daten liest und die ECC neu berechnet und mit
der geschriebenen ECC vergleicht, würde der Kontrollmechanismus greifen.

Wie "merkt" die HDD beim Schreiben also Fehler der Sektoren?
Post by Marcel Müller
Man sollte sich von der Vorstellung trennen, das irgendein modernes
Medium überhaupt die ihm anvertraute Information mit hinreichend großer
Wahrscheinlichkeit 1:1 hält, als dass man es für irgendetwas gebrauchen
könnte. Die Fehlerkorrekturen werden ständig gebraucht (bei CD, DVD, HDD
etc.). Ohne Korrektur arbeiten Disketten und analoge Kassetten.
...
Ack! Aber dass Festplatten solche Fehler in dem Maß produzieren ist mir
doch ziemlich neu.

Ciao,
--
Georges Heinesch
Shinji Ikari
2008-04-20 13:49:50 UTC
Permalink
Guten Tag.
Post by Georges Heinesch
Post by Marcel Müller
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
Soweit ich weiß geht beides.
<staune!> Ich habe Seagate und WD Platten, jedoch habe ich noch bei
keinem der Tools (aktuel, von den hersteller Websites) eine solche
Funktion entdeckt.
Dito.
Post by Georges Heinesch
Auch im Betriebssystem ist mir so etwas noch nicht
begegnet! Bitte um Angaben wo dies zu finden ist ... ;)
Das ging schon bei MS-DOS:
VERIFY=ON

Bei aktuellen Systemen hat man sowas entweder gut versteckt oder
leider entfernt.
Da ich aber auch einem OS gesteuerten Verify nicht vertraue und auch
Probleme nach laengerer Lagerzeit begegnet/erkennen will, greife ich
eben zu komplett nachtraeglichen Prueflaeufen.
Post by Georges Heinesch
Post by Marcel Müller
Sinn ergibt das Verify aber eigentlich nur, wenn nahezu alle Komponenten
einen geeigneten Validierungsschritt durchführen. Also, Parity bei den
Kabeln, ECC beim RAM u.s.w.
Kling logisch. Ist das praktisch durchführbar?
Hm. dazu ein paar Worte:
Ein User, der in der Lage ist Firmwares und Kontroller-BIOSse nach
eigenem Belieben umzuprogrammieren kann das alles in der Praxis
relaieren.
Doch sind das kaum noch normale User, sondern sehr hoch zu schaetzende
Spezialisten.
Der normale User, kann in der Tiefe der Hardware/Software nichts
nachruesten, was vom Hersteller nicht schon eingebaut wurde.
In so fern ist fuer die meisten User zu sagen. Nein, in deren Praxis
koennen sie diese Funktionen nicht durchfuehren lassen.

Deshalb bleibt nur auf OS oder gar manueller Programm-Ebene mit
Zusatzfunktionen einen kompletten verify-lauf nachtraeglich
durchzufuehren. Der Vorteil ist, dass man dann die gesamte Kette von
Datenquelle bis zum Datenziel in (optimaler Weise) einem Zusatzschritt
ueberprueft.

Einen schoenen (aber leider auch hinkenden) Vergleich kann man zur
DVD-RAM und der DVD+-R sehen.
Bei DVD-Ram wird (sofern nicht abgeschaltet) ein geschriebener
Datensatz wirklich neu eingelesen und kontrolliert. Leider wird das
Medium deshalb nur halb so schnell geschrieben und hat gerade bei
diversen Nutzern keinen so grossen Anklang gefunden. Auch dadurch war
der Absatz nicht so gross, die Preise purzelten nicht, dadurch war es
teurer, die Akzeptanz stieg nicht, .... <Kreislauf>
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141Kbyte <155KByte geloescht.
Marcel Müller
2008-04-20 20:27:04 UTC
Permalink
Hallo,

Georges Heinesch wrote:
[Datenfehler]
Post by Georges Heinesch
Post by Marcel Müller
das kann man nicht sagen. Es könnten sogar die Cache-RAMs der Platten
sein. Nur ist der im PC verbaute Consumer-Ramsch die häufigste
Ursache. Davon sind mittlerweile auch Server zu einem gewissen Grad
betroffen, oder wer hat noch ECC-RAMs?
Also wenn man soweit gehen muss um inkonsistente Daten zu erklären, dann
kann man wohl aufhören nach den Ursachen zu suchen.
jein. Es ist schon besorgniserregend, wenn offenbar gehäuft Datenfehler
auftreten.
Post by Georges Heinesch
Dann kann es ja
alles sein (Kabel, Stromversorgung, RAM, WLAN Störung, ...).
Nicht unbedingt. WLAN arbeitet mit Fehlerkorrektur und -erkennung. Die
Kabel haben eine Parity-Leitung (jedenfalls wenn man von den nicht
ernstzunehmenden IDE-PIO-Modi absieht), PCI ebenfalls. Interne
CPU-Caches haben meist ECC - so kann der Hersteller besser Testen.
Netzteil erzeugt bevor es einzelne Datenfehler gibt, meist gehäuft
unsystematische Abstürze, oft vorrangig im Idle-Betrieb, und
Kaltstartprobleme. Und von dem, was jetzt noch übrig bleibt, ist das RAM
die häufigste Ursache. Wohl dem der ECC-RAMs und einen Chipsatz, der das
beherrscht, hat.
Post by Georges Heinesch
Ich dachte
hisher immer das physikalische Beschreiben sei die Hauptfehlerquelle.
Letztlich schon, aber die wird von der Platte gut kompensiert. (OK, für
WLAN gilt ungefähr dasgleiche)
Post by Georges Heinesch
Post by Marcel Müller
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
Soweit ich weiß geht beides.
<staune!> Ich habe Seagate und WD Platten, jedoch habe ich noch bei
keinem der Tools (aktuel, von den hersteller Websites) eine solche
Funktion entdeckt. Auch im Betriebssystem ist mir so etwas noch nicht
begegnet! Bitte um Angaben wo dies zu finden ist ... ;)
Sorry, ihr habt recht. Mir war als wäre das auf SCSI Mode Page 7. Das
sind aber nur die Parameter für das Verify. Für aktiviertes Verify muss
der Treiber statt dem Kommando WRITE (0x2A) WRITE AND VERIFY (0x2E)
senden. Für ATAPI-Devices gilt üblicherweise ähnliches.
Post by Georges Heinesch
Post by Marcel Müller
...
Sinn ergibt das Verify aber eigentlich nur, wenn nahezu alle
Komponenten einen geeigneten Validierungsschritt durchführen. Also,
Parity bei den Kabeln, ECC beim RAM u.s.w.
Kling logisch. Ist das praktisch durchführbar?
Bei den Wesentlichen Komponenten: ja. Einige haben es ja schon (s.o.).
Der größte Engpass ist i.d.R. das RAM. Und dafür gibt es schon seit
bestimmt 15 Jahren ECC-RAMs und davor gab es schon RAMs mit Parity (im
Prinzip das gleiche, nur anders genutzt). Mein uralt 486-er hat
beispielsweise RAM mit Parity-Check. Das war damals Standard. In Zeiten
von "Geiz ist Geil" wurde das allerdings wegrationalisiert. Das hatte
neben den 10% niedrigeren Kosten den Riesenvorteil, dass nun auch leicht
defekte RAMs nicht gleich wieder zurückkamen, da der Rechner dies oft
gar nicht bemerkte, oder die Symptome derart diffus sind, dass es alles
sein kann. Mit Parity oder ECC kommt die Meldung "Parity-Error, System
halted" o.ä. - eindeutiger geht es nicht.

Wofür es keinen vernünftigen Schutz gibt ist der Chipsatz selbst und die
CPU. Defekte in der CPU äußern sich nur selten als Bitfehler, beim
Chipsatz kommt das allerdings schon vor.
Post by Georges Heinesch
Post by Marcel Müller
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.
Hier muss man aber weiter erklären. ECC mit Rückrechnung der Daten ist
schön und gut, aber wie funktioniert das? Wird die ECC vom HDD
Controller berechnet und mitsamt den Daten auf die HDD geschrieben?
Ja.
Post by Georges Heinesch
In
dem Fall bestände keine Kontrolle ob die Daten richtig geschrieben sind
da alles in einem Rutsch ohne Kontrolle geschrieben wird, ohne zu lesen.
Ebenfalls ja.
Post by Georges Heinesch
Wenn die HDD jedoch die Daten liest und die ECC neu berechnet und mit
der geschriebenen ECC vergleicht, würde der Kontrollmechanismus greifen.
Ja, alledings hat ECC eine gewisse Redundanz. Ähnlich, wie RAID5.
Dadurch kann eine bestimmte Menge gekippter Bits korrigiert werden. Eine
größere Menge gekippter Bits kann üblicherweise zumindest erkannt
werden. Das gibt dann die berühmten defekten Sektoren.
Post by Georges Heinesch
Wie "merkt" die HDD beim Schreiben also Fehler der Sektoren?
Gar nicht. Sie schreibt ein paar zusätzliche, redundante Informationen,
um ihre Chancen später beim Lesen zu verbessern.
Post by Georges Heinesch
Post by Marcel Müller
Man sollte sich von der Vorstellung trennen, das irgendein modernes
Medium überhaupt die ihm anvertraute Information mit hinreichend
großer Wahrscheinlichkeit 1:1 hält, als dass man es für irgendetwas
gebrauchen könnte. Die Fehlerkorrekturen werden ständig gebraucht (bei
CD, DVD, HDD etc.). Ohne Korrektur arbeiten Disketten und analoge
Kassetten.
...
Ack! Aber dass Festplatten solche Fehler in dem Maß produzieren ist mir
doch ziemlich neu.
Bezieht sich das jetzt auf die Fehler aus dem OP oder die per ECC
korrigierten Fehler?
Ersteres war m.E. niemals ein Fehler der HDD. Letzteres ist hal so. Es
ist einfach viel einfacher und billiger, die Daten 20% redundant zu
schreiben, als jedes einzelne Bit hinreichend sicher zu machen. 20%
größere Bits wäre dafür nämlich bei Weitem unzureichend.


Marcel
Richard W. Könning
2008-04-20 23:45:01 UTC
Permalink
Post by Marcel Müller
[Datenfehler]
Bei den Wesentlichen Komponenten: ja. Einige haben es ja schon (s.o.).
Der größte Engpass ist i.d.R. das RAM. Und dafür gibt es schon seit
bestimmt 15 Jahren ECC-RAMs und davor gab es schon RAMs mit Parity (im
Prinzip das gleiche, nur anders genutzt). Mein uralt 486-er hat
beispielsweise RAM mit Parity-Check. Das war damals Standard. In Zeiten
von "Geiz ist Geil" wurde das allerdings wegrationalisiert. Das hatte
Nun ja, Parity liefert i.w. nur ein eindeutigeres und frühzeitigeres
Fehlersignal, ansonsten war der Anwendernutzen imho eher begrenzt. Und
ich denke, daß die Speicherqualität seit damals sich deutlich
verbessert hat. Wenn ich an die Speicherchips (4Kx1, iirc 2114 oder
2147) meines ersten Rechners denke, ein Totalausfall, mehrere Chips
mit Bitfehlern, einer ausgerechnet an der Stelle, wo die Adresse der
seriellen Schnitstelle stand, dann hat sich seit damals die Qualität
ganz bedeutend verbessert.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Marcel Müller
2008-04-21 10:16:26 UTC
Permalink
Hallo,
Post by Richard W. Könning
Nun ja, Parity liefert i.w. nur ein eindeutigeres und frühzeitigeres
Fehlersignal, ansonsten war der Anwendernutzen imho eher begrenzt.
der Nutzen liegt darin, dass Speicherfehler sehr viel früher auffallen
und vor allem nicht unbemerkt bleiben. Praktisch wird ein guter Teil
aller Speicherzellen nach dem Schreiben nie mehr gelesen, bevor sie
erneut überschrieben werden. Diese Fehler deckt eine Parity/ECC-Prüfung
auf. (In eine Cache-Line werden die Zellen meist schon mal geladen.)

Es ist immer gut zu wissen, wie es um die Daten bestellt ist. Nicht
validierte Daten ist wie eine Statistik ohne Konfidenzintervall (also so
wie 80% aller veröffentlichen Statistiken) - ohne Glauben geht das
nichts. Und bis man den Fehler bemerkt ist der Schaden schon groß.
Post by Richard W. Könning
Und
ich denke, daß die Speicherqualität seit damals sich deutlich
verbessert hat. Wenn ich an die Speicherchips (4Kx1, iirc 2114 oder
2147) meines ersten Rechners denke, ein Totalausfall, mehrere Chips
mit Bitfehlern, einer ausgerechnet an der Stelle, wo die Adresse der
seriellen Schnitstelle stand, dann hat sich seit damals die Qualität
ganz bedeutend verbessert.
Absolut richtig. Aber die Frage ist, ob die Qualität im selben
Verhältnis gestiegen ist, wie die Kapazität. Wenn nicht, wird es von der
Wahrnehmung her eher schlechter.


Marcel
Richard W. Könning
2008-04-21 19:47:08 UTC
Permalink
Post by Marcel Müller
Hallo,
Post by Richard W. Könning
Nun ja, Parity liefert i.w. nur ein eindeutigeres und frühzeitigeres
Fehlersignal, ansonsten war der Anwendernutzen imho eher begrenzt.
der Nutzen liegt darin, dass Speicherfehler sehr viel früher auffallen
und vor allem nicht unbemerkt bleiben. Praktisch wird ein guter Teil
aller Speicherzellen nach dem Schreiben nie mehr gelesen, bevor sie
erneut überschrieben werden. Diese Fehler deckt eine Parity/ECC-Prüfung
auf. (In eine Cache-Line werden die Zellen meist schon mal geladen.)
Das ist das, was ich mit "eindeutigeres und frühzeitigeres
Fehlersignal" meinte. Aber was der Anwender eigentlich will, ist ein
Speicher ohne Fehler. ECC hilft, diesem Ziel näher zu kommen, Parity
nicht.
Post by Marcel Müller
Post by Richard W. Könning
Und
ich denke, daß die Speicherqualität seit damals sich deutlich
verbessert hat. Wenn ich an die Speicherchips (4Kx1, iirc 2114 oder
2147) meines ersten Rechners denke, ein Totalausfall, mehrere Chips
mit Bitfehlern, einer ausgerechnet an der Stelle, wo die Adresse der
seriellen Schnitstelle stand, dann hat sich seit damals die Qualität
ganz bedeutend verbessert.
Absolut richtig. Aber die Frage ist, ob die Qualität im selben
Verhältnis gestiegen ist, wie die Kapazität. Wenn nicht, wird es von der
Wahrnehmung her eher schlechter.
Zumindestens im Vergleich zu den von mir erwähnten 4K-Speicherchips
ist die Qualität dramatisch gestiegen. Selbst wenn ich den
Totalausfall vernachlässige, komme ich auf 5-10 Fehler auf 8 kByte.
Wäre die Qualität gleichgeblieben, dann hätte man bei 2 GB Speicher
mehr als eine Million fehlerhafter Speicherzellen, mit anderen Worten,
funktionierende Computer wären äußerst selten.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-23 17:41:45 UTC
Permalink
Hallo.
Post by Marcel Müller
...
Dann kann es ja alles sein (Kabel, Stromversorgung, RAM, WLAN Störung,
...).
Nicht unbedingt. WLAN arbeitet mit Fehlerkorrektur und -erkennung. Die
Kabel haben eine Parity-Leitung (jedenfalls wenn man von den nicht
...
Ich meinte nicht, dass diese Teile des Rechners selbst fehler machen
(die ggf. durch mechanismen korrigiert werden), sondern dass diese Teile
u.U. Fehler in den Festplatten produzieren (durch Stromspitzen,
Magnetismus, ...)
Post by Marcel Müller
<staune!> Ich habe Seagate und WD Platten, jedoch habe ich noch bei
keinem der Tools (aktuel, von den hersteller Websites) eine solche
Funktion entdeckt. Auch im Betriebssystem ist mir so etwas noch nicht
begegnet! Bitte um Angaben wo dies zu finden ist ... ;)
Sorry, ihr habt recht. Mir war als wäre das auf SCSI Mode Page 7. Das
sind aber nur die Parameter für das Verify. Für aktiviertes Verify muss
der Treiber statt dem Kommando WRITE (0x2A) WRITE AND VERIFY (0x2E)
senden. Für ATAPI-Devices gilt üblicherweise ähnliches.
Kann man die denn im OS einstellen, wenn nicht in der Platte selbst?
Post by Marcel Müller
Post by Marcel Müller
...
Sinn ergibt das Verify aber eigentlich nur, wenn nahezu alle
Komponenten einen geeigneten Validierungsschritt durchführen. Also,
Parity bei den Kabeln, ECC beim RAM u.s.w.
Kling logisch. Ist das praktisch durchführbar?
Bei den Wesentlichen Komponenten: ja. Einige haben es ja schon (s.o.).
... (verify after write)
Und bei den Festplatten?
Post by Marcel Müller
Wenn die HDD jedoch die Daten liest und die ECC neu berechnet und mit
der geschriebenen ECC vergleicht, würde der Kontrollmechanismus greifen.
Ja, alledings hat ECC eine gewisse Redundanz. Ähnlich, wie RAID5.
Dadurch kann eine bestimmte Menge gekippter Bits korrigiert werden. Eine
größere Menge gekippter Bits kann üblicherweise zumindest erkannt
werden. Das gibt dann die berühmten defekten Sektoren.
Das macht auch Sinn. Ich habe jedoch auf meinen Platten jede Menge
inkonsistenter Daten. Ich werde heute Abend (oder morgen) einen neuen
Artikel diesbezüglich schreiben.
Post by Marcel Müller
Ack! Aber dass Festplatten solche Fehler in dem Maß produzieren ist
mir doch ziemlich neu.
Bezieht sich das jetzt auf die Fehler aus dem OP oder die per ECC
korrigierten Fehler?
Aus dem OP. Ich möchte wissen wann ich Fehler habe (Meldung der Platten
dass Fehler nicht gelesen werden können). Dies dürfte i.d.R. nur der
Fall sein wenn der ECC Mechanismus zur Wiederherstellung versagt hat.

Gruß,
--
Georges Heinesch
Georges Heinesch
2008-04-23 17:57:44 UTC
Permalink
Post by Marcel Müller
...
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.
Zwischenfrage ... wenn ein Sektor falsche Daten liefert, die mittels ECC
korrigiert werden können, wird der Sektor dann trotzdem remapped? Oder
wird nur der Sektor remapped, der nicht wiederherstellbare daten liefert?

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-24 02:07:09 UTC
Permalink
Post by Georges Heinesch
Post by Marcel Müller
...
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.
Zwischenfrage ... wenn ein Sektor falsche Daten liefert, die mittels ECC
korrigiert werden können, wird der Sektor dann trotzdem remapped? Oder
wird nur der Sektor remapped, der nicht wiederherstellbare daten liefert?
Bei SCSI-Platten gibt es eine Reihe von Bits, mit denen man das
Verhalten einstellen kann. Beim Lesen wird sowieso nur dann remapped
(falls überhaupt), wenn die Daten durch wiederholtes Lesen und/oder
Verwendung des ECC wiederhergestellt werden konnten, da andernfalls
ein nicht lesbarer Block durch einen lesbaren mit falschen Daten
ersetzt wird.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-05-01 09:45:02 UTC
Permalink
Post by Richard W. Könning
Post by Georges Heinesch
Post by Marcel Müller
...
Post by Georges Heinesch
Genau das ist der Punkt. Wie funktioniert der?
Genau wie ggf. beim RAM: ECC Prüfsummen. Diese können bestimmte Fehler
im Gegensatz zu CRC auch korrigieren.
Zwischenfrage ... wenn ein Sektor falsche Daten liefert, die mittels ECC
korrigiert werden können, wird der Sektor dann trotzdem remapped? Oder
wird nur der Sektor remapped, der nicht wiederherstellbare daten liefert?
Bei SCSI-Platten gibt es eine Reihe von Bits, mit denen man das
Verhalten einstellen kann.
Es wundert mich, dass man im Netz keine detaillierten Infos über das
Verhalten des Remapping findet (ich habe jedenfalls nichts gefunden was
nicht trivial wäre).
Post by Richard W. Könning
Beim Lesen wird sowieso nur dann remapped
(falls überhaupt), wenn die Daten durch wiederholtes Lesen und/oder
Verwendung des ECC wiederhergestellt werden konnten,
Dass bei Verwendung des ECC (ohne wiederholtes Lesen) remapped wird ist
nicht so sicher. Angeblich wird das Benutzen des ECC als mehr oder
weniger "normale" Sache bei HDDs angesehen. Wenn jedesmal remapped
würde, gäbe es schon bald keine Reserve Sektoren mehr (wurde irgendwann
in den letzten Tagen hier geschrieben).

Dass beim wiederholten Lesen remapped wird, leuchtet schon eher ein.
Post by Richard W. Könning
da andernfalls
ein nicht lesbarer Block durch einen lesbaren mit falschen Daten
ersetzt wird.
Logisch!

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-24 13:11:39 UTC
Permalink
Post by Georges Heinesch
Zwischenfrage ... wenn ein Sektor falsche Daten liefert, die mittels ECC
korrigiert werden können, wird der Sektor dann trotzdem remapped? Oder
Nein. ECC ist fuer heutige Festplatten stinknormales Business.
Mit welcher Frequenz das passiert, koennen Besitzer von Seagate-Platten
sogar beobachten - Seagate exponiert das als einer der wenigen
Hersteller via SMART.

Das ist btw. auch der Grund dafuer, dass Festplatten inzwischen i.d.R.
deutlich schneller schreiben als lesen.
Post by Georges Heinesch
wird nur der Sektor remapped, der nicht wiederherstellbare daten liefert?
Korrekt.


regards
Mario
--
<delta> talk softly and carry a keen sword
Georges Heinesch
2008-04-25 08:31:51 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
...
Post by Georges Heinesch
Zwischenfrage ... wenn ein Sektor falsche Daten liefert, die mittels ECC
korrigiert werden können, wird der Sektor dann trotzdem remapped? Oder
Nein. ECC ist fuer heutige Festplatten stinknormales Business.
Mit welcher Frequenz das passiert, koennen Besitzer von Seagate-Platten
sogar beobachten - Seagate exponiert das als einer der wenigen
Hersteller via SMART.
Das ist btw. auch der Grund dafuer, dass Festplatten inzwischen i.d.R.
deutlich schneller schreiben als lesen.
Ist aber nicht so toll. Dann häufen sich die Fehler bis die Daten auf
einmal nicht mehr recoverable sind.

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-25 14:10:10 UTC
Permalink
Post by Georges Heinesch
Ist aber nicht so toll. Dann häufen sich die Fehler bis die Daten auf
einmal nicht mehr recoverable sind.
Yep, genau das passiert.


regards
Mario
--
Und wie jede Sprache, so hat auch PHP ein Anwendungsgebiet, fuer das es
besonders gut geeignet ist. Soweit ich sehen kann, handelt es sich dabei
um das sogenannte "ins Knie schiessen".
-- Volker Birk, de.alt.sysadmin.recovery
Marcel Müller
2008-05-02 07:34:03 UTC
Permalink
Hallo,
Post by Georges Heinesch
Post by Mario 'BitKoenig' Holbe
Nein. ECC ist fuer heutige Festplatten stinknormales Business.
Mit welcher Frequenz das passiert, koennen Besitzer von Seagate-Platten
sogar beobachten - Seagate exponiert das als einer der wenigen
Hersteller via SMART.
Ist aber nicht so toll. Dann häufen sich die Fehler bis die Daten auf
einmal nicht mehr recoverable sind.
nein, so schlimm ist es nicht. Die Tatsache, das ECC nötig war, heißt
für sich erstmal nicht, das es beim nächsten Mal notwendigerweise wieder
erforderlich oder gar schlimmer ist. ECC wird verwendet um mit
statistischen Fehlern aufgrund einer Vielzahl von Ursachen umzugehen.
Etliche davon sind nichtreproduzierbarer Natur. So z.B. das
Verstärkerrauschen im besonderen bei hoher Temperatur, EMV-Störungen
oder noch leicht schlingernde Köpfe nach einem Spurwechsel. Lediglich
gekippte magnetische Domänen haben einen permanenten Charakter. Aber
auch das hängt zum guten Teil mit festen Oberflächendefekten zusammen,
die eben so häufig sind, dass es effizienter ist, sie zu korrigieren als
immer gleich ganze Sektoren ungenutzt zu lassen. Einzig das
thermodynamische Kippen von Domänen durch den Tunneleffekt ist
kummulativer Natur. Dagegen hilft wiederum den Sektor einfach neu zu
schreiben, denn damit werden die Korrekturmechanismen zwischenzeitlich
zur Verbesserung der Daten angewendet. Also auch nicht wirklich ein
Grund den Sektor zu remappen.

Was wirklich böse ist, ist eine Beschädigung der Köpfe oder der Mechanik
sowie der Servoinformationen. Aber dann ist die Platte eigentlich als
defekt zu bezeichnen. All das äußert sich üblicherweise in einem Anstieg
nicht mehr lesbarer oder remappter Sektoren (im Memoriam Deathstar).
Ursachen sind beispielsweise beschädigte Köpfe (z.B. Degradation der
GMR-Schicht) durch Headcrash (thermischer Schaden) oder Alterung
(Diffusion), Schmiermittel an den Köpfen (falsche Flughöhe) oder
beschädigte Lager (Gleichlaufprobleme) oder gekippte Domänen in den
Servoinformationen. Letztere dienen zum Halten der Spurlage und sind ab
Werk auf das Medium aufgebacht. Die Platte selbst ist nicht in der Lage
selbige zu schreiben. Ein Low-Level-Format ist also gar nicht möglich.


Marcel
Georges Heinesch
2008-05-02 17:54:25 UTC
Permalink
Post by Marcel Müller
Hallo,
Post by Georges Heinesch
Post by Mario 'BitKoenig' Holbe
Nein. ECC ist fuer heutige Festplatten stinknormales Business.
Mit welcher Frequenz das passiert, koennen Besitzer von Seagate-Platten
sogar beobachten - Seagate exponiert das als einer der wenigen
Hersteller via SMART.
Ist aber nicht so toll. Dann häufen sich die Fehler bis die Daten auf
einmal nicht mehr recoverable sind.
nein, so schlimm ist es nicht. Die Tatsache, das ECC nötig war, heißt
für sich erstmal nicht, das es beim nächsten Mal notwendigerweise wieder
...
Sehr interessant! Hier sind schon einige Fragen beantwortet, die ich mir
schon länger gestellt habe. Gibt es im Web Einzelheiten dieser Thematik?
Weder wiki, noch google konnte helfen.

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-20 13:26:55 UTC
Permalink
Guten Tag
Post by Georges Heinesch
Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert) auf
dem Verbund (RAID5).
Dann koennte da noch ein problem vorhanden sein: gekippte Bits.
Festplatten sind keine wirklichen Langzeitspeicher.
Deshalb kontrolliere ich meine groesseren Nutzdaten gelegentlich mit
einem (Batch) groesstenteils automatisierten Durchlauf und habe
zusaetzlich Backup(s).
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
OS und/oder Kontroller.
Post by Georges Heinesch
Es ging mir im ursprünglichen Posting eher darum, ob die Festplatte die
Daten, die die Festplatte erhält ordnungsgemäß physikalisch geschrieben
werden.
Nein. Die Nutzdaten werden direkt nach dem Schreiben nicht inhaltlich
kontrolliert. Wenn die HDD auf Sektorfehler trifft, wird das aber
dennoch erkannt, verzeichnet (S.M.A.R.T.) und ausgelagert.
Post by Georges Heinesch
Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
... bis sie nach langer Lagerzeit vielleicht kippen.
Post by Georges Heinesch
Alle Fehler die nachher auftreten würden, wären zu einem späteren
Zeitpunkt auf irgend eine Weise (?) hinzugeschustert worden.
...sofern das Medium fuer jahrelanges stabiles Lagern vorgesehen
waere.
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141Kbyte <155KByte geloescht.
Georges Heinesch
2008-04-23 17:54:47 UTC
Permalink
Hallo.
Post by Shinji Ikari
...
Post by Georges Heinesch
Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert) auf
dem Verbund (RAID5).
Dann koennte da noch ein problem vorhanden sein: gekippte Bits.
Festplatten sind keine wirklichen Langzeitspeicher.
Deshalb kontrolliere ich meine groesseren Nutzdaten gelegentlich mit
einem (Batch) groesstenteils automatisierten Durchlauf und habe
zusaetzlich Backup(s).
Unter Linux?
Was macht dieses Batch genau?
Post by Shinji Ikari
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
OS und/oder Kontroller.
Ist das mit WinXP möglich? Ich habe nie etwas derartiges gesehen ?!?!
Der Kontroller (Areca ARC-1210) hat's nicht!
Post by Shinji Ikari
Post by Georges Heinesch
Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
.... bis sie nach langer Lagerzeit vielleicht kippen.
... und das vom ECC möglicherweise korrigiert wird (wenn möglich).
Post by Shinji Ikari
Post by Georges Heinesch
Alle Fehler die nachher auftreten würden, wären zu einem späteren
Zeitpunkt auf irgend eine Weise (?) hinzugeschustert worden.
....sofern das Medium fuer jahrelanges stabiles Lagern vorgesehen
waere.
Wie soll man die Information bzgl. "stabiles Lagern" das aus den
Datasheets der Festplatten entnehmen?

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-23 21:23:36 UTC
Permalink
Guten Tag
Post by Georges Heinesch
Post by Shinji Ikari
Post by Georges Heinesch
Die Files lagen 1-2 Jahre unberührt (werder gelesen, noch verändert) auf
dem Verbund (RAID5).
Dann koennte da noch ein problem vorhanden sein: gekippte Bits.
Festplatten sind keine wirklichen Langzeitspeicher.
Deshalb kontrolliere ich meine groesseren Nutzdaten gelegentlich mit
einem (Batch) groesstenteils automatisierten Durchlauf und habe
zusaetzlich Backup(s).
Unter Linux?
Noe. WindowsXP
Post by Georges Heinesch
Was macht dieses Batch genau?
Es ruft vorhandene (Freeware) DOS-Tools auf, die in allen
Verzeichnissen die vorgefertigten CRC32 Checksummen nehmen und mit den
Files vergleichen. Das Ergebnis wird in eine Extra-Datei gespeichert
die ich dann spaeter manuell einfach nach Begriffen "missing",
"error", etc.. durchsuche.
Dann kann ich manuell sehen, welche Dateien Probleme haben und selber
entscheiden, was ich mache. in der Regel ueberschreibe ich die defekte
Datei dann mit dem Backup und checke danach erneut.
Post by Georges Heinesch
Post by Shinji Ikari
Post by Georges Heinesch
Post by Marcel Müller
Man kann es aber anders einstellen (Verify). Das ist natürlich lahm.
Wo einstellen? Im Betriebssystem oder der Firmware der Platte?
OS und/oder Kontroller.
Ist das mit WinXP möglich? Ich habe nie etwas derartiges gesehen ?!?!
Ich habe es dort auch noch nicht entdeckt.
Deshalb nutze ich ja die Moegloichkeit der Checksummen oder beim
Kopiervorgang des binaervergleiches.
Post by Georges Heinesch
Post by Shinji Ikari
Post by Georges Heinesch
Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
.... bis sie nach langer Lagerzeit vielleicht kippen.
... und das vom ECC möglicherweise korrigiert wird (wenn möglich).
... sofern die HDD ueberhaupt der Meinung ist diese fehlerkorrektur
ueberhaupt einsetzen zu muessen.
Post by Georges Heinesch
Post by Shinji Ikari
Post by Georges Heinesch
Alle Fehler die nachher auftreten würden, wären zu einem späteren
Zeitpunkt auf irgend eine Weise (?) hinzugeschustert worden.
....sofern das Medium fuer jahrelanges stabiles Lagern vorgesehen
waere.
Wie soll man die Information bzgl. "stabiles Lagern" das aus den
Datasheets der Festplatten entnehmen?
ALLE Festplatten sind NICHT fuer langzeitiges stabiles Lagern gedacht.
Es ist fuer Langzeitarchivierung (ohne ueberpruefug und Extra
Fehlerkorrektur) das absolut falsche Medium.
Wenn man Festplatten fuer langzeitarchivierung verwenden will (was ich
persoenlich mache), erfordert es eben zusaetzliche
Sicherungsmassnahmen: Backups, gelegentliche Ueberpruefungen,
gekegentliches umspeichern, etc...
Je mehr Daten auf einer HDD verweilen, desto eher werden die
physikalischen Grenzen ausgereizt und desto eher koennen dann doch
vorhandene Probleme zutage treten.
Eine 340MB HDD von frueher habe ich aus Spass im Regal liegen und
schaue aus Neugier nach einigen Monaten mmer wieder d'rauf: sie hat
noch kein Bit verloren oder gekippt. Doch bei HDDs, der heutigen Zeit,
die einem Bit erheblich weniger mechnaische Flaeche auf dem Medium
bieten und diverse andere physikalische Eigenschaften immer weiter an
die Grenzen geschoben haben, habe ich das Vertrauen/diese Erfahrung
nicht.
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141kByte <155kByte geloescht.
Georges Heinesch
2008-04-24 09:04:09 UTC
Permalink
...
Post by Georges Heinesch
Post by Shinji Ikari
Post by Georges Heinesch
Angenommen die Daten im Cache sind richtig, wenn die Platte einen read
after write Mechanismus hätte wären die Daten konsistent auf der Platte.
.... bis sie nach langer Lagerzeit vielleicht kippen.
... und das vom ECC möglicherweise korrigiert wird (wenn möglich).
.... sofern die HDD ueberhaupt der Meinung ist diese fehlerkorrektur
ueberhaupt einsetzen zu muessen.
Wann ist die HDD denn der "Meinung" dass dies der Fall sein soll? Für
mich wäre es ja logisch, dass die CRC bei jedem Sektor beim lesen
überprüft wird. Aber das scheint ja nicht der fall zu sein, wenn ich das
richtig aus einem anderen Artikel gedeutet habe.
Post by Georges Heinesch
Wie soll man die Information bzgl. "stabiles Lagern" das aus den
Datasheets der Festplatten entnehmen?
ALLE Festplatten sind NICHT fuer langzeitiges stabiles Lagern gedacht.
Es ist fuer Langzeitarchivierung (ohne ueberpruefug und Extra
Fehlerkorrektur) das absolut falsche Medium.
Wenn man Festplatten fuer langzeitarchivierung verwenden will (was ich
persoenlich mache), erfordert es eben zusaetzliche
Sicherungsmassnahmen: Backups, gelegentliche Ueberpruefungen,
gekegentliches umspeichern, etc...
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-24 13:13:56 UTC
Permalink
Guten Tag
Post by Georges Heinesch
.... sofern die HDD ueberhaupt der Meinung ist diese fehlerkorrektur
ueberhaupt einsetzen zu muessen.
Wann ist die HDD denn der "Meinung" dass dies der Fall sein soll?
Wenn sie feststellt, dass das gelieferte Signal beim Auslesen der
Stelle nicht eindeutig (genug) ist.
Post by Georges Heinesch
Für
mich wäre es ja logisch, dass die CRC bei jedem Sektor beim lesen
überprüft wird.
Man koennte eine entsprechende schnelle Logik implementieren. Aber in
Zeiten in denen man jeden Cent dreimal umdreht entscheidet man sich
vielleicht zwischen Geschwindigkeit (= weglassen jeder Ueberpruefung),
billig (= nicht unbedingt die schnellste Ueberpruefungselektronik
verbauen) & Notwendigkeit (=wenn sowieso die meisten Daten fehlerfrei
gelesen werden, warum dann alle pruefen?).
Post by Georges Heinesch
Aber das scheint ja nicht der fall zu sein, wenn ich das
richtig aus einem anderen Artikel gedeutet habe.
Sonst gaebe es ja auch kaum noch unerkannte Fehlerquellen zwischen
HDD-Anschluss (SAS/SATA/PATA/SCSI) und Magnetflaeche.
Post by Georges Heinesch
ALLE Festplatten sind NICHT fuer langzeitiges stabiles Lagern gedacht.
Es ist fuer Langzeitarchivierung (ohne ueberpruefug und Extra
Fehlerkorrektur) das absolut falsche Medium.
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?
Sofern die HDD irgendwelche Fehler als Fehler erkennt, wird sie im
Rahmen der Moeglichkeiten diese versuchen zu beheben: ja.
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141kByte <155kByte geloescht.
Georges Heinesch
2008-04-25 08:37:08 UTC
Permalink
Post by Shinji Ikari
...
Post by Georges Heinesch
Für
mich wäre es ja logisch, dass die CRC bei jedem Sektor beim lesen
überprüft wird.
Man koennte eine entsprechende schnelle Logik implementieren. Aber in
Zeiten in denen man jeden Cent dreimal umdreht entscheidet man sich
vielleicht zwischen Geschwindigkeit (= weglassen jeder Ueberpruefung),
billig (= nicht unbedingt die schnellste Ueberpruefungselektronik
verbauen) & Notwendigkeit (=wenn sowieso die meisten Daten fehlerfrei
gelesen werden, warum dann alle pruefen?).
Warum überlässt man die Entscheidung Schnelligkeit versus
Datensicherheit nicht dem User *'%$§& !!!??? Gibt es keine Platten, wo
man dies in irgend einer Form in der Firmware beeinflussen kann?
Post by Shinji Ikari
Post by Georges Heinesch
Post by Shinji Ikari
ALLE Festplatten sind NICHT fuer langzeitiges stabiles Lagern gedacht.
Es ist fuer Langzeitarchivierung (ohne ueberpruefug und Extra
Fehlerkorrektur) das absolut falsche Medium.
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?
Sofern die HDD irgendwelche Fehler als Fehler erkennt, wird sie im
Rahmen der Moeglichkeiten diese versuchen zu beheben: ja.
Laut Mario, nein. news:fuq0ub$be4$***@inn-newsserver.rz.tu-ilmenau.de

?

Gruß,
--
Georges Heinesch
Shinji Ikari
2008-04-25 19:59:40 UTC
Permalink
Guten Tag
Post by Georges Heinesch
Warum überlässt man die Entscheidung Schnelligkeit versus
Datensicherheit nicht dem User *'%$§& !!!???
Macht man doch.
Wer Datensicherheit haben will kauft nicht ATA 500GB fuer aktuell
unter 100 Euro.
Wer das macht, kauft billiug und schnell aber nicht zwingend sicher.

Da aber die Mehrzahl der Leute eben das gemacht hat und die Hersteller
nicht fuer eine Minderzahl der Leute 500GB fuer >1000Euro in
ausreichender menge absetzen koennen, hat man sowas eben nicht
wirklich entwickelt.
Post by Georges Heinesch
Gibt es keine Platten, wo
man dies in irgend einer Form in der Firmware beeinflussen kann?
Aufgrund geringer Nachfrage und vermutlich zu hohen Kosten: nein.
Wenn ueberhaupt, findest Du es im Profisektor.
Doch werden Normaluser wohl eher gegenrechnen, dass
Backups/Raid/etc... erheblich billiger sein werden.
Ich koennte mir 10 HDDs mit 500GB fuer je ca. 80 Euro leisten anstatt
einer extrem sicheren 500GB fuer 1000Euro.
Ja, ich wuerde lieber die billigeren Varianten nehmen, da ich eben mit
Checksummen und Backup(s) arbeite.
--
MfG, Shinji
P.S.:Wegen Viren/Wuermern werden Mails >141kByte <155kByte geloescht.
Marc Stibane
2008-04-27 16:26:15 UTC
Permalink
Post by Georges Heinesch
Warum überlässt man die Entscheidung Schnelligkeit versus
Datensicherheit nicht dem User *'%$§& !!!??? Gibt es keine Platten, wo
man dies in irgend einer Form in der Firmware beeinflussen kann?
--
In a world without walls and fences,
who needs windows and gates?
Michael Baeuerle
2008-04-24 13:33:22 UTC
Permalink
Post by Georges Heinesch
.... sofern die HDD ueberhaupt der Meinung ist diese fehlerkorrektur
ueberhaupt einsetzen zu muessen.
Wann ist die HDD denn der "Meinung" dass dies der Fall sein soll? Für
mich wäre es ja logisch, dass die CRC bei jedem Sektor beim lesen
überprüft wird. Aber das scheint ja nicht der fall zu sein, wenn ich das
richtig aus einem anderen Artikel gedeutet habe.
Mir faellt da nur der Fall "AV Modus" ein, wo das nicht der Fall sein
koennte. Es gibt Platten die immer so arbeiten oder sich darauf
umschalten lassen fuer Audio- und Videozwecke (daher der Name).

In diesem Modus macht eine Platte absichtlich keine oder weniger
Fehlerkorrektur und liefert ggf. auch falsche Daten aus statt eine
Fehlermeldung zu produzieren (vergleichbar mit CD-Audio vs. CD-ROM). Bei
AV hat man lieber kurz einen Fehler als einen langen Haenger. Da aber
Recovery per ECC nicht nennenswert Zeit kostet wird die Platte das IMHO
immer machen und lediglich die langwierigen Retries weglassen.
Post by Georges Heinesch
[...]
ALLE Festplatten sind NICHT fuer langzeitiges stabiles Lagern gedacht.
Es ist fuer Langzeitarchivierung (ohne ueberpruefug und Extra
Fehlerkorrektur) das absolut falsche Medium.
Wenn man Festplatten fuer langzeitarchivierung verwenden will (was ich
persoenlich mache), erfordert es eben zusaetzliche
Sicherungsmassnahmen: Backups, gelegentliche Ueberpruefungen,
gekegentliches umspeichern, etc...
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?
Davon darfst du ausgehen. Das duerfte heute der Default aller Platten
sein wenn man nichts anderes eingestellt hat.


Micha
Mario 'BitKoenig' Holbe
2008-04-24 13:38:18 UTC
Permalink
Post by Michael Baeuerle
AV hat man lieber kurz einen Fehler als einen langen Haenger. Da aber
Recovery per ECC nicht nennenswert Zeit kostet wird die Platte das IMHO
Das kostet nennenswert Zeit. Vergleich mal die Schreib- und
Lesegeschwindigkeit heutiger Festplatten.


regards
Mario
--
I've never been certain whether the moral of the Icarus story should
only be, as is generally accepted, "Don't try to fly too high," or
whether it might also be thought of as, "Forget the wax and feathers
and do a better job on the wings." -- Stanley Kubrick
Michael Baeuerle
2008-04-24 15:22:55 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
AV hat man lieber kurz einen Fehler als einen langen Haenger. Da aber
Recovery per ECC nicht nennenswert Zeit kostet wird die Platte das IMHO
Das kostet nennenswert Zeit. Vergleich mal die Schreib- und
Lesegeschwindigkeit heutiger Festplatten.
Habe mir mal die Werte der Cheetah 15K.4 angesehen (weil deren Manual
hier gerade rumliegt). Ist schon etwas aelter aber schon noch eine
"heutige" Platte. Da kann ich nichts derartiges rauslesen:
Die Dauertransferrate ist nicht getrennt nach read/write angegeben
sondern ein Wert, hier STR = max. 96MByte/s. Es steht auch explizit
dabei, dass Lesen und Schreiben mit Interleave 1 moeglich ist.

Ich finde die Begruendung auch nicht einleuchtend. Beim Schreiben muss
der ECC ja schliesslich generiert werden, was IMHO aehnlich viel Zeit
wie dessen Pruefung beim Lesen benoetigen duerfte.


Micha
Mario 'BitKoenig' Holbe
2008-04-24 17:29:32 UTC
Permalink
Post by Michael Baeuerle
Post by Mario 'BitKoenig' Holbe
Das kostet nennenswert Zeit. Vergleich mal die Schreib- und
Lesegeschwindigkeit heutiger Festplatten.
Habe mir mal die Werte der Cheetah 15K.4 angesehen (weil deren Manual
hier gerade rumliegt).
omg
Ich fuehl mich dann einfach mal verarscht, das ist immerhin die fuer
Dich angenehmere der zwei Alternativen die mir grad einfallen.
Post by Michael Baeuerle
Ich finde die Begruendung auch nicht einleuchtend. Beim Schreiben muss
der ECC ja schliesslich generiert werden, was IMHO aehnlich viel Zeit
wie dessen Pruefung beim Lesen benoetigen duerfte.
Nein.
Generierung: u=vG
Pruefung: Hu=0
Korrektur: u=vG sowie Vergleich und Korrektur

Ergo:
Beim Schreiben brauchst Du im wesentlichen nur eine Matrixmultiplikation
pro Datenwort.
Beim Lesen im fehlerfreien Fall brauchst Du auch nur eine
Matrixmultiplikation pro Datenwort (und einen vernachlaessigbaren
Test auf Null).
Beim Lesen im Fehlerfall brauchst Du eine weitere Matrixmultiplikation,
den Vergleich der Pruefbits und die entsprechende Inversion der
jeweiligen Datenbits.

Der Aufwand beim Lesen im Fehlerfall ist also im wesentlichen etwas mehr
als doppelt so gross wie beim Schreiben. Tritt der Fehlerfall haeufig
auf (wie bei heutigen Festplatten), hast Du entsprechend haeufig den
erhoehten Aufwand.


regards
Mario
--
() Ascii Ribbon Campaign
/\ Support plain text e-mail
Michael Baeuerle
2008-04-25 08:53:32 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Post by Mario 'BitKoenig' Holbe
Das kostet nennenswert Zeit. Vergleich mal die Schreib- und
Lesegeschwindigkeit heutiger Festplatten.
Habe mir mal die Werte der Cheetah 15K.4 angesehen (weil deren Manual
hier gerade rumliegt).
omg
Ich fuehl mich dann einfach mal verarscht, das ist immerhin die fuer
Dich angenehmere der zwei Alternativen die mir grad einfallen.
Gut, also noch das Manual der aktuellen Barrcuda 7200.11 besorgt - eine
Terabyte-Platte hat ja hoffentlich eine dir genehme Fehlerrate: Es steht
aber auch nichts anderes drin. Hier ist die STR eben 105MByte/s,
ebenfalls kein Wort, dass sie beim Lesen langsamer waere.
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Ich finde die Begruendung auch nicht einleuchtend. Beim Schreiben muss
der ECC ja schliesslich generiert werden, was IMHO aehnlich viel Zeit
wie dessen Pruefung beim Lesen benoetigen duerfte.
Nein.
Generierung: u=vG
Pruefung: Hu=0
Korrektur: u=vG sowie Vergleich und Korrektur
Beim Schreiben brauchst Du im wesentlichen nur eine Matrixmultiplikation
pro Datenwort.
Beim Lesen im fehlerfreien Fall brauchst Du auch nur eine
Matrixmultiplikation pro Datenwort (und einen vernachlaessigbaren
Test auf Null).
Also so wie ich unterstellt habe.
Post by Mario 'BitKoenig' Holbe
Beim Lesen im Fehlerfall brauchst Du eine weitere Matrixmultiplikation,
den Vergleich der Pruefbits und die entsprechende Inversion der
jeweiligen Datenbits.
Der Aufwand beim Lesen im Fehlerfall ist also im wesentlichen etwas mehr
als doppelt so gross wie beim Schreiben. Tritt der Fehlerfall haeufig
auf (wie bei heutigen Festplatten), hast Du entsprechend haeufig den
erhoehten Aufwand.
Du behauptest also, es wuerden so viele Fehler auftreten die per ECC
korrigiert werden muessen, dass die STR durch die dadurch enstehende
zusaetzliche CPU-Last signifikant sinkt? Das will ich nicht glauben,
sollte es wirklich so sein, dann ist dein Argument aber berechtigt.

Also mal in die Manuals geschaut:
Bei der Cheetah 15K.4 steht:

| Recovered Data Less than 10 errors in 10^12 bits transferred

10^12 / (8 * 1GByte) = 125
Also im Mittel weniger als ein korrigierter Fehler pro 125GByte. Es
steht allerdings dabei:

| Recoverable Data errors will use correction, although ECC
| on-the-fly is not considered for purposes of recovered
| error specifications.
| Recovered Data error rate is determined using read bits
| transferred for recoverable errors occurring during a read,
| and using write bits transferred for recoverable errors
| occurring during a write.

Was auch immer das heissen mag. Werte fuer die Barracuda 7200.11 stehen
gar keine im Manual.

Die CPU der Platte hat aber IMHO bei ca. 100MByte/s Datenrate sicher
keine 100% Last weil der Cache schneller bedient werden kann, d.h. die
CPU haette selbst wenn die Rechnerei tatsaechlich oefter anfallen wuerde
auch Zeit dafuer uebrig.

Gib doch bitte mal deine Quelle fuer die langsameren Lesewerte an.


Micha
Mario 'BitKoenig' Holbe
2008-04-25 14:23:51 UTC
Permalink
Post by Michael Baeuerle
Gut, also noch das Manual der aktuellen Barrcuda 7200.11 besorgt - eine
*seufz* Also doch nicht die erste der beiden Alternativen die mir
eingefallen waren - Du bist tatsaechlich nur bedauernswert naiv. Warum
sollte man etwas messen, wenn mans auch nachlesen kann, ne? Auf Papier
steht ja bekanntlich immer die Wahrheit - insbesondere in der Bild und
in den Datasheets von Herstellern ueber ihre Produkte.
Okay... bedauernswert war falsch - beneidenswert ist besser, das Leben
kann so einfach sein.

Ich hab hier z.B. ne ST3250410AS, die schreibt am Anfang mit 97MB/s und
liest am Anfang mit 94MB/s - weiter hinten wirds langsamer, logisch.
Grad heute hab ich ne MHW2080AT bekommen, die schreibt am Anfang mit
36.8MB/s und liest am Anfang mit 36.5MB/s. Beide Platten haben genau
null reallocated sectors.
Post by Michael Baeuerle
Du behauptest also, es wuerden so viele Fehler auftreten die per ECC
korrigiert werden muessen, dass die STR durch die dadurch enstehende
zusaetzliche CPU-Last signifikant sinkt? Das will ich nicht glauben,
Wow, den Controller auf der Platte als CPU zu bezeichnen is auch ned
schlecht.
Post by Michael Baeuerle
Gib doch bitte mal deine Quelle fuer die langsameren Lesewerte an.
Meine Benchmarks. Mach Deine eigenen wenn Du mir nicht glaubst. Oder leb
halt weiter in der Welt Deines wahren Papiers.


regards
Mario
--
We know that communication is a problem, but the company is not going to
discuss it with the employees.
-- Switching supervisor, AT&T Long Lines Division
Michael Baeuerle
2008-04-25 16:17:57 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Gut, also noch das Manual der aktuellen Barrcuda 7200.11 besorgt - eine
*seufz* Also doch nicht die erste der beiden Alternativen die mir
eingefallen waren - Du bist tatsaechlich nur bedauernswert naiv.
Tut mir leid wenn ich dich entaeuscht habe.
Post by Mario 'BitKoenig' Holbe
Warum
sollte man etwas messen, wenn mans auch nachlesen kann, ne? Auf Papier
steht ja bekanntlich immer die Wahrheit - insbesondere in der Bild und
in den Datasheets von Herstellern ueber ihre Produkte.
Okay... bedauernswert war falsch - beneidenswert ist besser, das Leben
kann so einfach sein.
Tja, das Problem ist halt dass ich keine aktuelle ATA Platte zum Messen
besitze mit der ich messen koennte.
Post by Mario 'BitKoenig' Holbe
Ich hab hier z.B. ne ST3250410AS, die schreibt am Anfang mit 97MB/s und
liest am Anfang mit 94MB/s - weiter hinten wirds langsamer, logisch.
Grad heute hab ich ne MHW2080AT bekommen, die schreibt am Anfang mit
36.8MB/s und liest am Anfang mit 36.5MB/s. Beide Platten haben genau
null reallocated sectors.
Und das nennst du jetzt einen _signifikanten_ Unterschied? Mess besser
nochmal ob es nicht 36.55MByte/s gewesen sind ;-)

Dass der Unterschied wirklich durch die Platte verursacht wurde und
nicht etwa am HA oder Treiber gelegen hat und woanders genauso gross ist
kannst du eigentlich auch nicht wissen. Also da sind mir die
Datenblattwerte doch lieber ...
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Du behauptest also, es wuerden so viele Fehler auftreten die per ECC
korrigiert werden muessen, dass die STR durch die dadurch enstehende
zusaetzliche CPU-Last signifikant sinkt? Das will ich nicht glauben,
Wow, den Controller auf der Platte als CPU zu bezeichnen is auch ned
schlecht.
Er ist natuerlich viel mehr als das. Aber was glaubst du worauf die
Firmware der Platte laeuft? Hier als Beispiel der Controller einer alten
IBM DFHS wo man das noch sieht:
Loading Image...
Man erkennt deutlich die 80C186-20 CPU von AMD, hier als separater Chip
verbaut. Das fette Teil von TI daneben ist vermutlich ein DSP, also auch
eine CPU. Und auch neuere SCSI-Protokollchips haben eine eigene CPU
integriert. Bei aktuellen Billigplatten mag der ganze Controller in ein
einzelnes Gehaeuse integriert sein, aber das aendert nichts an seiner
Funktionsweise.


Micha
Richard W. Könning
2008-04-26 01:59:03 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Gut, also noch das Manual der aktuellen Barrcuda 7200.11 besorgt - eine
*seufz* Also doch nicht die erste der beiden Alternativen die mir
eingefallen waren - Du bist tatsaechlich nur bedauernswert naiv. Warum
sollte man etwas messen, wenn mans auch nachlesen kann, ne? Auf Papier
steht ja bekanntlich immer die Wahrheit - insbesondere in der Bild und
in den Datasheets von Herstellern ueber ihre Produkte.
Bei den Seek-Zeiten stehen für Read und Write unterschiedliche Werte,
warum sollte der Hersteller bei den Transfer-Raten signifikant
unterschiedliche Werte verschweigen?
Post by Mario 'BitKoenig' Holbe
Okay... bedauernswert war falsch - beneidenswert ist besser, das Leben
kann so einfach sein.
Ich vermute eher, daß Du Opfer von "Wer Mist mißt, mißt Mist" geworden
bist ;-).
Post by Mario 'BitKoenig' Holbe
Ich hab hier z.B. ne ST3250410AS, die schreibt am Anfang mit 97MB/s und
liest am Anfang mit 94MB/s - weiter hinten wirds langsamer, logisch.
Grad heute hab ich ne MHW2080AT bekommen, die schreibt am Anfang mit
36.8MB/s und liest am Anfang mit 36.5MB/s. Beide Platten haben genau
null reallocated sectors.
Erstens fehlt die Angabe des Benchmark-Tools. Die Werte der letzteren
Platte liegen so dicht beieinander, daß sie praktisch identisch sind,
jedenfalls sind sie kein besserer Beleg für Deine Behauptung als
Kaffeesatzleserei. Für die Werte der ersten Platte gilt im Grunde das
gleiche. Die Differenz kann durchaus mit Asymmetrien zwischen
Read-Ahead-Mechanismus und Schreibpuffer zu tun haben, ohne genauere
Analyse aus der Differenz auf Performance-Probleme bei
ECC-Berechnungen zu schließen ist wiederum hochgradige
Kaffeesatzleserei.
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Du behauptest also, es wuerden so viele Fehler auftreten die per ECC
korrigiert werden muessen, dass die STR durch die dadurch enstehende
zusaetzliche CPU-Last signifikant sinkt? Das will ich nicht glauben,
Wow, den Controller auf der Platte als CPU zu bezeichnen is auch ned
schlecht.
Was gibt es daran auszusetzen?
Post by Mario 'BitKoenig' Holbe
Post by Michael Baeuerle
Gib doch bitte mal deine Quelle fuer die langsameren Lesewerte an.
Meine Benchmarks. Mach Deine eigenen wenn Du mir nicht glaubst. Oder leb
halt weiter in der Welt Deines wahren Papiers.
Du meinst, man soll Deinen undokumentierten Benchmarks, Deiner
undokumentierten Testmaschine und Deiner gewagten Interpretation mehr
glauben als dokumentierte Werte aus einem Datenblatt? Für mich sind
jedenfalls die Hersteller-Datenblätter in jedem Fall
vertrauenswürdiger als eine windige Argumentation wie die Deine.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-25 08:40:21 UTC
Permalink
Post by Michael Baeuerle
...
Post by Georges Heinesch
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?
Davon darfst du ausgehen. Das duerfte heute der Default aller Platten
sein wenn man nichts anderes eingestellt hat.
Da ist Mario anerer Ansicht. news:fuq0ub$be4$***@inn-newsserver.rz.tu-ilmenau.de

Gruß,
--
Georges Heinesch
Michael Baeuerle
2008-04-25 10:23:31 UTC
Permalink
Post by Michael Baeuerle
...
Post by Georges Heinesch
Wenn man die Daten alle von Zeit zu Zeit liest (nur liest!), werden doch
somit auch Softerrors /(recoverable errors, die durch die ECC
korrigiert werden können) entdeckt un der Sektor remappt. Richtig?
Davon darfst du ausgehen. Das duerfte heute der Default aller Platten
sein wenn man nichts anderes eingestellt hat.
Er hat wohl auch recht, ich nehme meine Aussage zurueck. ECC errors
passieren offenbar zu haeufig, als dass man da sofort remappen wuerde.
Bei der Cheetah 15K.4 steht im Manual einiges schwammiges zu dem Thema,
ich wuerde es so interpretieren:
Ein per ECC korrigierbarer Fehler wird einfach korrigiert, zaehlt nicht
als "recovered error" und fuehrt daher auch nicht zum remapping.
"Recovery" bedeutet hier, dass die ECC Korrektur fehlgeschlagen ist und
Retries zum Einsatz kamen. Diese Platte macht beim Lesen per default 11
Retries (einstellbar) und remapped falls damit die korrekten Daten
gewonnen werden konnten, das Remapping eingeschaltet ist (ARRE=1), der
AV-Modus ausgeschaltet ist (RC=0) und die konfigurierten Timeouts noch
nicht abgelaufen sind.

Das aendert aber nichts daran, dass die von dir genannten
Lesedurchlaeufe sinnvoll sind. Spaetestens beim ersten Retry passiert
dann schon das was du erreichen wolltest (Remapping ohne Datenverlust).
Die obige Platte macht das scheinbar sogar automatisch (nennt sich
"Background Media Scan"). Nach 500ms Idle legt sie damit los.


Micha
Rainer Zocholl
2008-04-19 19:14:00 UTC
Permalink
Post by Georges Heinesch
Hallo.
Wenn man 'mal einen Plattencrash hatte der Datenverlust mit sich
brachte, dann macht man sich seine Gedanken wie Fehler entstehen.
Es gibt harte und weiche fehler!
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
soft errors.
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben
Sektor defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?^
Ja, natürlich.
Alle sectoren der Platte sind mit CRC prüfsummen gesichert.
"eigentlich" kann eine Platte nur heile Daten liefern oder gar keine.

In deinem Fall sind die Daten vermutlich defekt geschrieben worden,
Du hast in deimem PC probleme mit RAM oder Datenkabeln.

Wenn Du Festplatten zum archivieren nehnem willst musst du diese
regelmässig "testlesen".
"Raparieren" kann die Platte nur, wenn du mit "badblocks"
einen "nicht destruktiven schreib test" machen lässt.
Die Platte mappt dann defekte Sektoren in reserve Sektoren um.
Ist natürlich riskant...aber besser heute per Test wissen das man Daten
verloren hat, als in 5 Jahre, wenn man sie vielleicht wirklich braucht
und bestimmt nicht noch wo anders herbekommen kann.



Rainer
--
Transparency International definiert Korruption als
Missbrauch von anvertrauter Macht zum privaten Nutzen oder Vorteil. [...]
Corruption is operationally defined as the misuse of entrusted power for
private gain. [...]
Georges Heinesch
2008-04-20 09:06:26 UTC
Permalink
Post by Rainer Zocholl
Es gibt harte und weiche fehler!
Kannst du bitte kurz erklären.
Software / Hardware?
Post by Rainer Zocholl
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
soft errors.
Ok. ?
Post by Rainer Zocholl
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben
Sektor defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?^
Ja, natürlich.
Wie funktioniert das denn? Ein read-after-write findet ja nicht statt.
Wie weiß die Platte dass ein fehler beim Schreiben entstanden ist?
Post by Rainer Zocholl
Alle sectoren der Platte sind mit CRC prüfsummen gesichert.
"eigentlich" kann eine Platte nur heile Daten liefern oder gar keine.
Also liegt die Vermutung nahe dass die Fehler beim Schreiben entstanden
sind.
Post by Rainer Zocholl
In deinem Fall sind die Daten vermutlich defekt geschrieben worden,
Du hast in deimem PC probleme mit RAM oder Datenkabeln.
Nein. Nie. Keine Reboots oder sonstige Probleme.
Post by Rainer Zocholl
Wenn Du Festplatten zum archivieren nehnem willst musst du diese
regelmässig "testlesen".
Diese Aussage lässt darauf schließen, dass Fehler auch im laufe der Zeit
entstehen können?
Post by Rainer Zocholl
"Raparieren" kann die Platte nur, wenn du mit "badblocks"
einen "nicht destruktiven schreib test" machen lässt.
Die Platte mappt dann defekte Sektoren in reserve Sektoren um.
Ist natürlich riskant...aber besser heute per Test wissen das man Daten
verloren hat, als in 5 Jahre, wenn man sie vielleicht wirklich braucht
und bestimmt nicht noch wo anders herbekommen kann.
Das mit dem "remappen" von schlechten Sektoren war mir auch nie richtig
verständlich. Du sagst dass dieses "remappen" nur vollzogen wird, wenn
es explizit vom User angestossen wird (wenn ich das richtig verstanden
habe)?

Diverse Tools zeigen bei meinen Festplatten jedoch etliche Sektoren, die
"remapped" wurden, ohne dass ich jemals bewusst einen solchen "remap"
Vorgang angestossen habe.

Gruß,
--
Georges Heinesch
Christoph Purrucker
2008-04-20 12:24:10 UTC
Permalink
Hallo Georges,
Post by Georges Heinesch
Post by Rainer Zocholl
Es gibt harte und weiche fehler!
Kannst du bitte kurz erklären.
Harte Fehler lassen sich nimmer korrigieren: Der Block ist unlesbar, für
immer verloren. Weiche Fehler lassen sich durch mehrfaches Lesen mit
statistischem 'schätzen' oder durch Prüfsummen, die die Platte ja intern
aufbaut, korrigieren.

Harte Fehler kann die Platte nicht mehr herzaubern: Der Sektor bleibt
defekt, bis dort wieder mal Daten hingeschrieben werden sollen und
werden dann bei der Gelegenheit gleich durch einen Reservesektor
ersetzt. Softerrors werden je nach Firmware einfach beim Lesen erst mal
aufgefrischt, oder durch einen Reservesektor gemappt.
Post by Georges Heinesch
Post by Rainer Zocholl
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
soft errors.
Ok. ?
Nein, Softerrors lassen sich ja einwandfrei und fürs Betriebssystem
transparent korrigieren.
Post by Georges Heinesch
Post by Rainer Zocholl
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben
Sektor defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?^
Wie funktioniert das denn? Ein read-after-write findet ja nicht statt.
Wie weiß die Platte dass ein fehler beim Schreiben entstanden ist?
wohl gar nicht. Obwohl es ja im ATA-Log auch Write-Errors gibt: irgendwo
muss die Platte also zumindest grobe Fehler beim Schreiben auch erkennen
können. Ob aber 100% aller potentieller Fehler erkannt werden, kann Dir
nur ein Festplatten-Firmware-Entwickler sagen (wenn er darf).
Post by Georges Heinesch
Post by Rainer Zocholl
Alle sectoren der Platte sind mit CRC prüfsummen gesichert.
"eigentlich" kann eine Platte nur heile Daten liefern oder gar keine.
Also liegt die Vermutung nahe dass die Fehler beim Schreiben entstanden
sind.
Genau. Oder es gibt den unwahrscheinlichen Fall, dass die CRC zufällig
wieder passt...
Post by Georges Heinesch
Post by Rainer Zocholl
In deinem Fall sind die Daten vermutlich defekt geschrieben worden,
Du hast in deimem PC probleme mit RAM oder Datenkabeln.
Nein. Nie. Keine Reboots oder sonstige Probleme.
Das heißt gar nix. Ich hatte einen Linux-'Server', der ist 24/7
durchgelaufen, aber ein RAM-Modul hat alle 100MB
Lese/Schreib-Operationen ein Bit kippen lassen. Da in dem Bereich des
Arbeitsspeichers Linux offensichtlich hauptsächlich Datenträger-Caches
untergebracht hat (genauer: Der RAM war hauptsächlich Datenträger-Cache
bei 1GB Speicher und nur wenigen laufenden Prozessen), wurde Kraut und
Rüben auf die Platten geschrieben und gelesen.
Post by Georges Heinesch
Post by Rainer Zocholl
Wenn Du Festplatten zum archivieren nehnem willst musst du diese
regelmässig "testlesen".
Diese Aussage lässt darauf schließen, dass Fehler auch im laufe der Zeit
entstehen können?
Ja. Gute Sektoren werden durch diverse Einflüsse (und wenns kosmische
Strahlung ist) magnetisch verändert, die Leseköpfe haben es immer
schwerer, die Daten zu entziffern bis irgendwann ein Bit kippt, das aber
durch die Prüfsummen repariert werden kann (=Softerror). Wird der
Sektor nie mehr gelesen, kann er theoretisch so schlecht werden, dass er
beim späteren erstmaligen Lesen gleich zum Harderror wird; dann hattest
Du Pech: Sowas sollte aber extrem selten sein.
Post by Georges Heinesch
Post by Rainer Zocholl
"Raparieren" kann die Platte nur, wenn du mit "badblocks" einen "nicht
destruktiven schreib test" machen lässt.
Die Platte mappt dann defekte Sektoren in reserve Sektoren um.
Ist natürlich riskant...aber besser heute per Test wissen das man
Daten verloren hat, als in 5 Jahre, wenn man sie vielleicht wirklich
braucht und bestimmt nicht noch wo anders herbekommen kann.
Das mit dem "remappen" von schlechten Sektoren war mir auch nie richtig
verständlich. Du sagst dass dieses "remappen" nur vollzogen wird, wenn
es explizit vom User angestossen wird (wenn ich das richtig verstanden
habe)?
Ich habs versucht, oben zu erklären. Das macht die Platte selbst. Du
musst nur einmal alle Daten von Sektor 0 bis Ende anfordern, den Rest
macht die Platte.
Post by Georges Heinesch
Diverse Tools zeigen bei meinen Festplatten jedoch etliche Sektoren, die
"remapped" wurden, ohne dass ich jemals bewusst einen solchen "remap"
Vorgang angestossen habe.
Profis haben einen RAID-Kontroller, der Scrubbing betreibt. Das
bedeutet, er fordert von allen Platten die Daten an, und vergleicht die
Ergebnisse (bei entsprechenden RAID-Leveln). Bei der Gelegenheit werden
ja außerdem alle Platten von vorne bis hinten gelesen und die Platten
können selbst eventuelle Softerrors korrigieren. Das Scrubbing machen
die Kontroller im Hintergrund, wenn das Betriebssystem nichts lesen oder
schreiben will, und zwar zum Teil rund um die Uhr: constant scrubbing

Übrigens kann auch das Linux-Software-RAID das Scrubbing, aber die
meisten billig-Fake-RAID-Kontroller ham davon leider noch nie was gehört.

Gruß,
cp
Rainer Zocholl
2008-04-20 15:09:00 UTC
Permalink
Post by Christoph Purrucker
Post by Georges Heinesch
Diese Aussage lässt darauf schließen, dass Fehler auch im laufe der
Zeit entstehen können?
Ja. Gute Sektoren werden durch diverse Einflüsse (und wenns kosmische
Strahlung ist)
Ich glaube das ist bei Platten noch nicht so weit, aber bei RAMs chips
Post by Christoph Purrucker
magnetisch verändert, die Leseköpfe haben es immer
schwerer, die Daten zu entziffern bis irgendwann ein Bit kippt, das
aber durch die Prüfsummen repariert werden kann (=Softerror). Wird
der Sektor nie mehr gelesen, kann er theoretisch so schlecht werden,
dass er beim späteren erstmaligen Lesen gleich zum Harderror wird;
dann hattest Du Pech: Sowas sollte aber extrem selten sein.
Post by Georges Heinesch
Post by Rainer Zocholl
"Raparieren" kann die Platte nur, wenn du mit "badblocks" einen
"nicht destruktiven schreib test" machen lässt.
Ich habs versucht, oben zu erklären. Das macht die Platte selbst. Du
musst nur einmal alle Daten von Sektor 0 bis Ende anfordern, den Rest
macht die Platte.
Jein. Ich hatte eine HD500 die das wohl nicht (mehr) konnte.
Das Linux bekam jedesmal einen harten lesefehler und war dann
unbedienbar. (*)
War nicht so tragisch es nur ne TV Aufzeichnung war.
Geholfen hat da aber jener "nicht destruktiver Schreibtest".
Allerdings:
Danach war der Fehler weg, aber kein neuer Sektor remapped worden..




(*)
Das erinnert mit an ein Sun auf deren SCSI Bus mal der Terminator
falschrum angschlossen war, der Datenbus also kurz geschlossen war:
Gab nur ne lakonische Meldung auf der console, das die Boot platte
weg sei. Nach korrekter Montage arbeitet die Maschine einfach weiter.
Windows hätte ne blue screen geworfen und linux sich aufgehagen...
Rainer
--
Transparency International definiert Korruption als
Missbrauch von anvertrauter Macht zum privaten Nutzen oder Vorteil. [...]
Corruption is operationally defined as the misuse of entrusted power for
private gain. [...]
Michael Baeuerle
2008-04-21 07:38:27 UTC
Permalink
Post by Rainer Zocholl
Post by Christoph Purrucker
Ich habs versucht, oben zu erklären. Das macht die Platte selbst. Du
musst nur einmal alle Daten von Sektor 0 bis Ende anfordern, den Rest
macht die Platte.
Jein. Ich hatte eine HD500 die das wohl nicht (mehr) konnte.
Das Linux bekam jedesmal einen harten lesefehler und war dann
unbedienbar. (*)
War nicht so tragisch es nur ne TV Aufzeichnung war.
Geholfen hat da aber jener "nicht destruktiver Schreibtest".
Ist ja auch logisch, bei einem nicht korrigierbaren Lesefehler darf die
Platte nicht einfach remappen. Das OS wuerde ansonsten ja ab diesem
Zeitpunkt falsche Daten und ein OK fuer diesen Block kriegen. Erst mit
einem Schreibbefehl auf den unlesbaren Block schickt das OS die Daten
offiziell ins Nirvana und die Platte darf remappen.
Post by Rainer Zocholl
Danach war der Fehler weg, aber kein neuer Sektor remapped worden..
Dann war das remapping abgeschaltet oder es waren einfach nur die Daten
kaputt und der Block an sich aber noch OK (mit den neuen Daten bestueckt
wieder lesbar). Einer Firmware mit so einem Algorithmus wuerde ich aber
eher nicht vertrauen wollen ...


Micha
Mario 'BitKoenig' Holbe
2008-04-22 11:50:45 UTC
Permalink
Post by Christoph Purrucker
Profis haben einen RAID-Kontroller, der Scrubbing betreibt. Das
bedeutet, er fordert von allen Platten die Daten an, und vergleicht die
Ergebnisse (bei entsprechenden RAID-Leveln). Bei der Gelegenheit werden
Das ist Unsinn. Das funktioniert nur bei RAID2 und das wird heute so gut
wie nicht mehr benutzt.
Was soll denn ein RAID1 oder ein RAID5 machen, wenn es feststellt, dass
die beiden Mirrors verschiedene Daten liefern oder dass die Parity-Bits
falsch sind? Was sind denn nun die korrekten Daten? Hat der erste Mirror
recht oder der zweite? Hat eine Daten-Disk (welche?) falsche Daten
geliefert oder die Parity-Disk?
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.


regards
Mario
--
The question of whether a computer can think is no more interesting than
the question of whether a submarine can swim. -- E. W. Dijkstra
Richard W. Könning
2008-04-22 23:40:04 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Christoph Purrucker
Profis haben einen RAID-Kontroller, der Scrubbing betreibt. Das
bedeutet, er fordert von allen Platten die Daten an, und vergleicht die
Ergebnisse (bei entsprechenden RAID-Leveln). Bei der Gelegenheit werden
Das ist Unsinn. Das funktioniert nur bei RAID2 und das wird heute so gut
wie nicht mehr benutzt.
Was soll denn ein RAID1 oder ein RAID5 machen, wenn es feststellt, dass
die beiden Mirrors verschiedene Daten liefern oder dass die Parity-Bits
falsch sind? Was sind denn nun die korrekten Daten? Hat der erste Mirror
Wie Du unten selbst schreibst sagt die betreffende Festplatte, daß sie
einen Fehler gefunden hat. Bei RAID 1 stehen dann die korrekten Daten
noch auf der anderen Platte, bei RAID 5 kann man sie mit Hilfe der
Parity-Information berechnen (bzw. wenn die Parity-Daten von dem
Fehler betroffen sind, dann kann man diese aus den noch vorhandenen
Daten berechnen).
Post by Mario 'BitKoenig' Holbe
recht oder der zweite? Hat eine Daten-Disk (welche?) falsche Daten
geliefert oder die Parity-Disk?
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
Post by Mario 'BitKoenig' Holbe
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Michael Baeuerle
2008-04-23 07:05:32 UTC
Permalink
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
recht oder der zweite? Hat eine Daten-Disk (welche?) falsche Daten
geliefert oder die Parity-Disk?
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
Ja, aber nur wenn die Platten diese Fehler selbst(!) erkennen und dem
Controller melden. Der Controller wird zugunsten der Performance i.d.R.
auch grottenfalsche Daten akzeptieren solange die Platte sagt sie seien
OK. Und sowas kommt wohl immer oefter vor.

Der Controller koennte in so einem Fall unter heftigem
Performanceverlust zwar erkennen, dass ein Fehler passiert ist, aber
selber lokalisieren und korrigieren koennte er ihn nicht wenn alle
Platten OK gemeldet haben. Vielleicht durch Mehrheitsentscheid bei RAID1
mit mehr als 2 Platten, aber das waere noch langsamer und haette <34%
Nettokapazitaet.
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Damit das Array mit der Redundanz weiterlaeuft wenn eine Platte einen
Fehler findet.


Micha
Richard W. Könning
2008-04-24 02:16:22 UTC
Permalink
Post by Michael Baeuerle
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
recht oder der zweite? Hat eine Daten-Disk (welche?) falsche Daten
geliefert oder die Parity-Disk?
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
Ja, aber nur wenn die Platten diese Fehler selbst(!) erkennen und dem
Controller melden. Der Controller wird zugunsten der Performance i.d.R.
Eben; und Mario versuchte zu suggerieren, daß eher das Gegenteil der
Fall ist.
Post by Michael Baeuerle
auch grottenfalsche Daten akzeptieren solange die Platte sagt sie seien
OK. Und sowas kommt wohl immer oefter vor.
Der Controller koennte in so einem Fall unter heftigem
Performanceverlust zwar erkennen, dass ein Fehler passiert ist, aber
selber lokalisieren und korrigieren koennte er ihn nicht wenn alle
Platten OK gemeldet haben. Vielleicht durch Mehrheitsentscheid bei RAID1
mit mehr als 2 Platten, aber das waere noch langsamer und haette <34%
Nettokapazitaet.
Eben, ein RAID ist dafür da, von den *Plattten* gemeldete Fehler zu
korrigieren, und nicht, wie Marios Darstellung es suggeriert, anstelle
der Platten selbst die Fehler festzustellen.
Post by Michael Baeuerle
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Damit das Array mit der Redundanz weiterlaeuft wenn eine Platte einen
Fehler findet.
Eben. Und Mario hat an dieser Stelle selbst dargelegt, daß man RAID
eben nicht für die *Feststellung*, sondern für die *Korrektur* eines
Fehlers verwendet.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-24 10:20:17 UTC
Permalink
Post by Richard W. Könning
...
Post by Michael Baeuerle
Ja, aber nur wenn die Platten diese Fehler selbst(!) erkennen und dem
Controller melden. Der Controller wird zugunsten der Performance i.d.R.
Eben; und Mario versuchte zu suggerieren, daß eher das Gegenteil der
Fall ist.
IMHO nein. Mario ging nur davon aus, dass die Festplatten keinen Fehler
ausgeben (was bei mir z.Z. der Fall ist), und der RAID Kontroller
prinzipbedingt nicht feststellen kann welche Platte den Fehler hat weil
keine Meldung vorhanden ist.
Post by Richard W. Könning
Post by Michael Baeuerle
auch grottenfalsche Daten akzeptieren solange die Platte sagt sie seien
OK. Und sowas kommt wohl immer oefter vor.
Der Controller koennte in so einem Fall unter heftigem
Performanceverlust zwar erkennen, dass ein Fehler passiert ist, aber
selber lokalisieren und korrigieren koennte er ihn nicht wenn alle
Platten OK gemeldet haben. Vielleicht durch Mehrheitsentscheid bei RAID1
mit mehr als 2 Platten, aber das waere noch langsamer und haette <34%
Nettokapazitaet.
Eben, ein RAID ist dafür da, von den *Plattten* gemeldete Fehler zu
korrigieren, und nicht, wie Marios Darstellung es suggeriert, anstelle
der Platten selbst die Fehler festzustellen.
Idem ... wenn der RAID Kontroller keine Fehlermeldung der Platten
erhällt sind die Daten für ihn ok, auch wenn "grottenfalsch". Wenn
Fehler bemerkt werden, dann wird korrigiert. Da hast du Recht!
Post by Richard W. Könning
Post by Michael Baeuerle
Damit das Array mit der Redundanz weiterlaeuft wenn eine Platte einen
Fehler findet.
Eben. Und Mario hat an dieser Stelle selbst dargelegt, daß man RAID
eben nicht für die *Feststellung*, sondern für die *Korrektur* eines
Fehlers verwendet.
RAID kann Dateninkonsistenzen feststellen. Diese können nur entstehen
wenn Sektorenfehler nicht gemeldet werden. Da kann RAID nichts machen,
da es nicht weiß von welcher Platte der Fehler stammt.

Wenn Fehler gemeldet werden, kann korrigiert werden, sonst nicht.

Gruß,
--
Georges Heinesch
Richard W. Könning
2008-04-25 01:59:58 UTC
Permalink
Post by Georges Heinesch
Post by Richard W. Könning
...
Eben. Und Mario hat an dieser Stelle selbst dargelegt, daß man RAID
eben nicht für die *Feststellung*, sondern für die *Korrektur* eines
Fehlers verwendet.
RAID kann Dateninkonsistenzen feststellen. Diese können nur entstehen
wenn Sektorenfehler nicht gemeldet werden. Da kann RAID nichts machen,
da es nicht weiß von welcher Platte der Fehler stammt.
Wenn Fehler gemeldet werden, kann korrigiert werden, sonst nicht.
Dein erster Satz paßt nicht zu Deinem vierten Satz. RAID könnte
Dateninkonsistenzen feststellen, tut es aber aus Performance-Gründen
nicht, sondern verläßt sich bei der Fehler*feststellung* auf die
entsprechende Funktionalität der einzelnen Platten und sorgt nur für
die Fehler*behebung*.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-25 08:44:59 UTC
Permalink
Post by Richard W. Könning
...
Post by Georges Heinesch
RAID kann Dateninkonsistenzen feststellen. Diese können nur entstehen
wenn Sektorenfehler nicht gemeldet werden. Da kann RAID nichts machen,
da es nicht weiß von welcher Platte der Fehler stammt.
Wenn Fehler gemeldet werden, kann korrigiert werden, sonst nicht.
Dein erster Satz paßt nicht zu Deinem vierten Satz. RAID könnte
Dateninkonsistenzen feststellen, tut es aber aus Performance-Gründen
nicht,
Ich meinte hiermit explizit angestossen, durch einen consistency check,
nicht im normalen Betrieb.
Post by Richard W. Könning
sondern verläßt sich bei der Fehler*feststellung* auf die
entsprechende Funktionalität der einzelnen Platten und sorgt nur für
die Fehler*behebung*.
Richtig!
Letzter Satz wäre der "bad block" Fall. Hier kann RAID helfen.

Ciao,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-24 13:07:10 UTC
Permalink
Post by Richard W. Könning
Eben; und Mario versuchte zu suggerieren, daß eher das Gegenteil der
Fall ist.
Nein, versuchte ich nicht. Christoph versuchte das. Ich habe ihm
lediglich widersprochen.


regards
Mario
--
I heard, if you play a NT-CD backwards, you get satanic messages...
That's nothing. If you play it forwards, it installs NT.
Richard W. Könning
2008-04-25 01:55:49 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Richard W. Könning
Eben; und Mario versuchte zu suggerieren, daß eher das Gegenteil der
Fall ist.
Nein, versuchte ich nicht. Christoph versuchte das. Ich habe ihm
lediglich widersprochen.
Das einzig problematische in Christophs Posting ist imho, daß er an
einer Stelle beim Scrubbing die Wendung "vergleicht die Ergebnisse"
anstatt korrekter "prüft die Ergebnisse" geschrieben hat.
Ansonsten sehe ich kein Problem mit seiner Darstellung: entweder die
Platte entdeckt einen Soft-Error und repariert ihn gegebenenfalls per
Remapping selber oder sie meldet einen Hard-Error, der dann mit der
RAID-Funktionalität repariert werden kann durch entweder explizites
"REASSIGN BLOCK" (bei SCSI-Platten) oder durch Rückschreiben des
defekten Blocks, was im Normalfall dann ein Remappen durch das
Laufwerk anstoßen sollte.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Christoph Purrucker
2008-04-25 19:04:44 UTC
Permalink
Hallo Richard,

Dann melde ich ich mich doch noch mal :)
Post by Richard W. Könning
Das einzig problematische in Christophs Posting ist imho, daß er an
einer Stelle beim Scrubbing die Wendung "vergleicht die Ergebnisse"
anstatt korrekter "prüft die Ergebnisse" geschrieben hat.
Na ja, wenn ich prüfe, dann vergleiche ich einen Prüfwert mit einem
Sollwert. Bei einem RAID-1 mit zwei Platten oder einem RAID-5 habe ich
aber keinen Sollwert, mit dem ich vergleichen könnte. Also kann ich
nicht prüfen.

Scrubbing macht nach meiner Definition bei
- RAID1: Lesen Sektor A von Platte 1 und Platte 2; Vergleichen von A1
und A2. Wenn gleich, dann nächster Sektor, wenn verschieden, dann den
Benutzer fragen, ob 1 oder 2 korrekt ist.
- RAID5: Lesen Stribe A von allen Platten; Vergleich ob A1+A2+A3...
gleich Parity, wenn OK, dann nächster Stribe, wenn verschieden, dann den
Beutzer fragen, ob die Daten oder das Parity defekt sind.

Merke: Wenn alle Platten sagen, sie liefern korrekte Daten, dann kann
der Raid-Kontroller durch obige Operation nur feststellen, dass ein
Platte lügt, aber nicht, welche das ist.

Übrigens gibt es beim Linux-Software-RAID-1 einige Situationen, wo obige
Operation Unterschiede zwischen den RAID-1 Platten findet, und das kein
Grund zur Sorge ist. Aber bei normalem Datenbetrieb darf das natürlich
nicht auftreten.
Post by Richard W. Könning
Ansonsten sehe ich kein Problem mit seiner Darstellung: entweder die
Platte entdeckt einen Soft-Error und repariert ihn gegebenenfalls per
Remapping selber oder sie meldet einen Hard-Error, der dann mit der
RAID-Funktionalität repariert werden kann durch entweder explizites
"REASSIGN BLOCK" (bei SCSI-Platten) oder durch Rückschreiben des
defekten Blocks, was im Normalfall dann ein Remappen durch das
Laufwerk anstoßen sollte.
Gruß,
cp
Richard W. Könning
2008-04-26 02:15:14 UTC
Permalink
Post by Christoph Purrucker
Post by Richard W. Könning
Das einzig problematische in Christophs Posting ist imho, daß er an
einer Stelle beim Scrubbing die Wendung "vergleicht die Ergebnisse"
anstatt korrekter "prüft die Ergebnisse" geschrieben hat.
Na ja, wenn ich prüfe, dann vergleiche ich einen Prüfwert mit einem
Sollwert. Bei einem RAID-1 mit zwei Platten oder einem RAID-5 habe ich
aber keinen Sollwert, mit dem ich vergleichen könnte. Also kann ich
nicht prüfen.
Doch, man kann prüfen, nämlich, ob der jeweilige Block erfolgreich
gelesen werden kann. Sollwert ist "Block kann gelesen werden".
Post by Christoph Purrucker
Scrubbing macht nach meiner Definition bei
- RAID1: Lesen Sektor A von Platte 1 und Platte 2; Vergleichen von A1
und A2. Wenn gleich, dann nächster Sektor, wenn verschieden, dann den
Benutzer fragen, ob 1 oder 2 korrekt ist.
- RAID5: Lesen Stribe A von allen Platten; Vergleich ob A1+A2+A3...
gleich Parity, wenn OK, dann nächster Stribe, wenn verschieden, dann den
Beutzer fragen, ob die Daten oder das Parity defekt sind.
Der Benutzer weiß nicht, welche Daten korrekt sind. Wenn Daten
RAID-mäßig inkonsistent sind, aber keine der Platten einen Lesefehler
meldet, dann hat man verloren und muß das Backup holen.
Post by Christoph Purrucker
Merke: Wenn alle Platten sagen, sie liefern korrekte Daten, dann kann
der Raid-Kontroller durch obige Operation nur feststellen, dass ein
Platte lügt, aber nicht, welche das ist.
Eben. Wenn diese Operation Inkonsistenzen liefert, dann treffen die
Annahmen, auf die RAID basiert, nicht zu und der RAID-Mechanismus hat
versagt; Zeit, um das Backup zu holen.

Scrubbing ist dafür da, die Datenblöcke nicht ewig herumgammeln zu
lassen, sondern bei Problemen rechtzeitig ein Remapping anzustoßen.
Ansonsten sammeln sich mit der Zeit wackelige Blöcke an, die für sich
allein dank RAID noch kein Problem darstellen (es sei denn, sie
treffen aufeinander, was aber eher unwahrscheinlich ist). Wenn aber
irgendwann eine Platte komplett ausfällt, dann stehen diese wackeligen
(d.h. mit einer gewissen Wahrscheinlichkeit nicht mehr lesbaren)
Blöcke ohne Parity da, mit deren Hilfe man sie rekonstruieren könnte.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-24 10:10:48 UTC
Permalink
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
Post by Christoph Purrucker
Profis haben einen RAID-Kontroller, der Scrubbing betreibt. Das
bedeutet, er fordert von allen Platten die Daten an, und vergleicht die
Ergebnisse (bei entsprechenden RAID-Leveln). Bei der Gelegenheit werden
Das ist Unsinn. Das funktioniert nur bei RAID2 und das wird heute so gut
wie nicht mehr benutzt.
Was soll denn ein RAID1 oder ein RAID5 machen, wenn es feststellt, dass
die beiden Mirrors verschiedene Daten liefern oder dass die Parity-Bits
falsch sind? Was sind denn nun die korrekten Daten? Hat der erste Mirror
Wie Du unten selbst schreibst sagt die betreffende Festplatte, daß sie
einen Fehler gefunden hat. Bei RAID 1 stehen dann die korrekten Daten
noch auf der anderen Platte, bei RAID 5 kann man sie mit Hilfe der
Parity-Information berechnen (bzw. wenn die Parity-Daten von dem
Fehler betroffen sind, dann kann man diese aus den noch vorhandenen
Daten berechnen).
Mario bezieht sich auf die Situation, wo die festplatten keine
Fehlermeldung ausgeben. In dem Fall hat er Recht. Der RAID Controller
kann es nicht wissen.
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
recht oder der zweite? Hat eine Daten-Disk (welche?) falsche Daten
geliefert oder die Parity-Disk?
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
RAID ist für Festplattenausfall, nicht für Datensicherheit (ausser RAID-2).
Post by Richard W. Könning
Post by Mario 'BitKoenig' Holbe
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Festplattenausfall.

Ich verstehe wie du denkst, da ich bis vor 2 Tagen auch noch mit dieser
Idee rumgelaufen bin. Dieser Thread hat jedoch gezeigt, dass RAID nicht
für Datensicherheit zuständig ist. Kann ich inzwischen bestätigen!

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-24 13:05:28 UTC
Permalink
Post by Richard W. Könning
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
Aber keine Fehler der Art Dateninkonsistenz. Wenn Du gelesen haettest
worauf ich geantwortet habe, waere Dir Der Zusammenhang nicht
entgangen.
Post by Richard W. Könning
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Um die Daten dann trotzdem noch zu bekommen.


regards
Mario
--
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten
Richard W. Könning
2008-04-25 02:13:09 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Richard W. Könning
Natürlich können auch die anderen RAID-Level Fehler korrigieren, sonst
würde man sie kaum verwenden.
Aber keine Fehler der Art Dateninkonsistenz. Wenn Du gelesen haettest
Weil man davon ausgeht, daß das die jeweilige Platte selber gut genug
kann.
Post by Mario 'BitKoenig' Holbe
worauf ich geantwortet habe, waere Dir Der Zusammenhang nicht
entgangen.
Post by Richard W. Könning
Wenn die Festplatten das tun, wofür braucht man nach Deiner obigen
Darstellung noch ein RAID?
Um die Daten dann trotzdem noch zu bekommen.
Eben. Die Platten sind für die Fehler*erkennung* zuständig und das
RAID für die Fehler*korrektur*.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-24 10:05:52 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
...
RAID Level ausser RAID2 koennen Fehler nur erkennen, nicht korrigieren.
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
stattdessen eine Fehlermeldung.
Genau das habe ich bis vor 2 Tagen auch gedacht!

Dann bin ich jetzt einmal gespannt wie du das hier erkl�rst ;) news:***@vo.lu

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-24 13:16:23 UTC
Permalink
Post by Georges Heinesch
Post by Mario 'BitKoenig' Holbe
Das ist heute aus genau aus einem Grund ausreichend: Weil Festplatten
dafuer sorgen, dass sie keine falschen Daten liefern, sondern
Genau das habe ich bis vor 2 Tagen auch gedacht!
Treiberfehler, RAM-Fehler, etc. pp.

Ich habe beispielsweise gerade eine Notebook-Festplatte, die einige...
sagen wir mal instbile Sektoren hat: Meistens kann sie sie nicht lesen,
reallokieren kann sie sie leider offenbar auch nicht. Wenn ich die
Platte an eine usb2ide bridge haenge und diese Sektoren lese, geht das
manchmal scheinbar gut und ich bekomme von Nullen (die stimmen) bis hin
zu merkwuerdigen Daten die auf keinem Fall von dieser Festplatte stammen
koennen (dafuer aber von einer anderen) zurueck. Klares Treiber-Problem.


regards
Mario
--
I've never been certain whether the moral of the Icarus story should
only be, as is generally accepted, "Don't try to fly too high," or
whether it might also be thought of as, "Forget the wax and feathers
and do a better job on the wings." -- Stanley Kubrick
Mario 'BitKoenig' Holbe
2008-04-24 13:36:19 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Treiberfehler, RAM-Fehler, etc. pp.
Ganz vergessen und evtl. realistischer: Rechner ausgeschaltet oder
abgestuerzt waehrend auf das RAID noch geschrieben wurde. Sowas fuehrt
bei Software-RAIDs und nicht-battery-backed Hardware-RAIDs auch gern mal
zu solchen Inkonsistenzen (Daten auf einem Mirror schon geschrieben, auf
dem anderen noch nicht oder Daten schon geschrieben, Parity noch nicht).


regards
Mario
--
File names are infinite in length where infinity is set to 255 characters.
-- Peter Collinson, "The Unix File System"
Georges Heinesch
2008-04-25 08:54:10 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Post by Mario 'BitKoenig' Holbe
Treiberfehler, RAM-Fehler, etc. pp.
Ganz vergessen und evtl. realistischer: Rechner ausgeschaltet oder
abgestuerzt waehrend auf das RAID noch geschrieben wurde. Sowas fuehrt
bei Software-RAIDs und nicht-battery-backed Hardware-RAIDs auch gern mal
zu solchen Inkonsistenzen (Daten auf einem Mirror schon geschrieben, auf
dem anderen noch nicht oder Daten schon geschrieben, Parity noch nicht).
Greift in meinem Fall auch nicht da die PGP Signature verifiziert wurde.

Gruß,
--
Georges Heinesch
Georges Heinesch
2008-04-25 08:52:46 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
...
Treiberfehler, RAM-Fehler, etc. pp.
Ich habe beispielsweise gerade eine Notebook-Festplatte, die einige...
sagen wir mal instbile Sektoren hat: Meistens kann sie sie nicht lesen,
reallokieren kann sie sie leider offenbar auch nicht. Wenn ich die
Platte an eine usb2ide bridge haenge und diese Sektoren lese, geht das
manchmal scheinbar gut und ich bekomme von Nullen (die stimmen) bis hin
zu merkwuerdigen Daten die auf keinem Fall von dieser Festplatte stammen
koennen (dafuer aber von einer anderen) zurueck. Klares Treiber-Problem.
Das hier scheint ein sporadisches Problem zu sein. Deuet IMHO auf RAM
hin, ist aber nicht mit meinem Problem zu vergleichen.

Ich habe die daen geschrieben, die PGP Signature erstellt, verglichen
(war ok, also waren die daten korrekt geschrieben). Jetzt nach 1-2
Jahren der Fehler (ohne Fehlermeldung!).

BTW ... was meinst du mit "Treiber-Problem"? Firmware der HDD?

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-25 14:14:01 UTC
Permalink
Post by Georges Heinesch
Post by Mario 'BitKoenig' Holbe
Ich habe beispielsweise gerade eine Notebook-Festplatte, die einige...
Das hier scheint ein sporadisches Problem zu sein. Deuet IMHO auf RAM
Nein, es deutet nicht auf RAM hin, der ist vollkommen okay. Es deutet
auf ein Treiberproblem hin. Der liefert schlicht Buffer aus, die er
nicht vorher gefuellt hat.
Post by Georges Heinesch
BTW ... was meinst du mit "Treiber-Problem"? Firmware der HDD?
Den Geraetetreiber. Die Firmware der Harddisk kann nicht an Daten
anderer Platten rankommen und die dann ausliefern - insbesondere dann
nicht, wenn sie hinter eine USB2IDE Bridge haengt und die anderen
Platten an diversen IDE Controllern.


regards
Mario
--
I thought the only thing the internet was good for was porn. -- Futurama
Georges Heinesch
2008-04-24 09:51:11 UTC
Permalink
Post by Christoph Purrucker
...
Post by Georges Heinesch
Post by Rainer Zocholl
Es gibt harte und weiche fehler!
Kannst du bitte kurz erklären.
Harte Fehler lassen sich nimmer korrigieren: Der Block ist unlesbar, für
immer verloren.
Du meinst, die Daten sind verloren (nicht der Sektor an sich), und ein
erneuter Schreibzugroff zu einem späteren Zeitpunckt kann erfolgreich sein?
Post by Christoph Purrucker
Weiche Fehler lassen sich durch mehrfaches Lesen mit
statistischem 'schätzen' oder durch Prüfsummen, die die Platte ja intern
aufbaut, korrigieren.
ECC kann die Daten wieder herstellen. Wenn die ECC Daten zwecks
Wiederherstellung der Nutzdaten herangezogen werden müssen, wird der
Datensektor neu geschrieben um einen nochmaligen Fehler beim Auslesen
der Nutzdaten zu verhindern. Das schreibst du ja weiter unten. Macht Sinn!
Post by Christoph Purrucker
Harte Fehler kann die Platte nicht mehr herzaubern: Der Sektor bleibt
defekt, bis dort wieder mal Daten hingeschrieben werden sollen und
werden dann bei der Gelegenheit gleich durch einen Reservesektor
ersetzt.
Hmmm ... siehe Frage oben bzgl. harderror.
Post by Christoph Purrucker
Softerrors werden je nach Firmware einfach beim Lesen erst mal
aufgefrischt, oder durch einen Reservesektor gemappt.
Ok!
Post by Christoph Purrucker
Post by Georges Heinesch
Post by Rainer Zocholl
Post by Georges Heinesch
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Wie ist das möglich?
soft errors.
Ok. ?
Nein, Softerrors lassen sich ja einwandfrei und fürs Betriebssystem
transparent korrigieren.
Harderrors? Diese werden ja AKAIK angezeigt (Lesefehler wird
ausgegeben). Das war jedoch nicht der Fall.

Was war es dann?
Post by Christoph Purrucker
Post by Georges Heinesch
Post by Rainer Zocholl
In deinem Fall sind die Daten vermutlich defekt geschrieben worden,
Du hast in deimem PC probleme mit RAM oder Datenkabeln.
Nein. Nie. Keine Reboots oder sonstige Probleme.
Das heißt gar nix. Ich hatte einen Linux-'Server', der ist 24/7
...
Ich habe die Signature der 4 besagten Files mit Sicherheit grenzender
Wahrscheinlichkeit nach dem Schreiben überprüft! Wie kann da später ein
Problem enstehen? Der Schreibvorgang war ok, und wenn der Lesevorgang
auf harderrors gestoßen wäre, hätte es Fehlermeldungen gegeben
(softerrors werden ja transparent korrigiert).

- ich habe geschrieben.
- das geschriebene wurde verifiziert (mittels PGP Signature Durchlauf).
- nach einige Zeit wurde gelesen und die Signature stimmte einfach nicht
mehr. Alles ohne Fehlermeldung.
Post by Christoph Purrucker
Post by Georges Heinesch
Diverse Tools zeigen bei meinen Festplatten jedoch etliche Sektoren,
die "remapped" wurden, ohne dass ich jemals bewusst einen solchen
"remap" Vorgang angestossen habe.
Profis haben einen RAID-Kontroller, der Scrubbing betreibt. Das
bedeutet, er fordert von allen Platten die Daten an, und vergleicht die
Ergebnisse (bei entsprechenden RAID-Leveln). Bei der Gelegenheit werden
ja außerdem alle Platten von vorne bis hinten gelesen und die Platten
können selbst eventuelle Softerrors korrigieren. Das Scrubbing machen
die Kontroller im Hintergrund, wenn das Betriebssystem nichts lesen oder
schreiben will, und zwar zum Teil rund um die Uhr: constant scrubbing
Mein ARC-1210 macht dies anscheinend auch, aber nur bei einem
consistency check.

Siehe hier:
***@vo.lu
--
Georges Heinesch
Christoph Purrucker
2008-04-24 18:53:30 UTC
Permalink
Hallo,
Post by Georges Heinesch
Du meinst, die Daten sind verloren (nicht der Sektor an sich), und ein
erneuter Schreibzugroff zu einem späteren Zeitpunckt kann erfolgreich sein?
Genau.
Post by Georges Heinesch
Was war es dann?
- ich habe geschrieben.
- das geschriebene wurde verifiziert (mittels PGP Signature Durchlauf).
- nach einige Zeit wurde gelesen und die Signature stimmte einfach nicht
mehr. Alles ohne Fehlermeldung.
Ja, dies erschüttert mein Weltbild. Die einzig mir schlüssige Erklärung
liegt darin, dass das RAM/CPU/Board defekt ist: Es wird jeweils eine
3-5GB große Datei geprüft und dabei kippt ein Bit aufm Bus/im RAM und
die Signatur stimmt nimmer. Das Problem ist ja, dass Du bei den vier
Dateien nicht weißt, ob immer das selbe gekippte Bit die Signatur
ungültig werden lässt.

Offene Fragen:

Hast Du das mehrfach reproduzieren können, dass immer die selben vier
Files kaputt sind? Reproduzierbar: Rechner aus - Hochfahren - eine
einzelne funktionierende Datei testen - runterfahren - hochfahren - eine
einzelne defekte Datei (mit möglichst gleicher Dateigröße) testen.

Du könntest auch eine Datei mehrfach (unter verschiedenen Namen) auf ne
andere Platte kopieren und dann binär vergleichen, ob irgendwo ein
kippendes Bit ist, oder die Daten immer gleich defekt von der
Quellplatte kommen. Alternativ kannst Du natürlich in einer Schleife
md5sum auf die Datei loslassen und schauen, ob auch nach Stunden immer
die selbe Summe rauskommt.

Cool wär jetzt natürlich, wenn Du ein Backup hättest, wo Du nachschauen
könntest, wie die Datei original aussah. Vielleicht ist ja viel mehr als
ein Bit 'gekippt' und irgendwer hat einfach an der Datei rumgespielt:
Bei Mp3 käme mir da etwa eine Playersoftware in den Sinn, die ungefragt
id3-Tags korrigiert...
Post by Georges Heinesch
Post by Christoph Purrucker
Das Scrubbing
machen die Kontroller im Hintergrund, wenn das Betriebssystem nichts
lesen oder schreiben will, und zwar zum Teil rund um die Uhr: constant
scrubbing
Mein ARC-1210 macht dies anscheinend auch, aber nur bei einem
consistency check.
Jo, manuell gibts das natürlich auch.

Gruß,
cp
Georges Heinesch
2008-04-26 18:12:08 UTC
Permalink
Hallo.

Ich mache ausnahmsweise ein "Paste As Quotation" von hier:
http://groups.google.com/group/de.comp.hardware.laufwerke.festplatten/msg/9d5c765b19de8484

Die Referenz in der Baumstruktur der News stimmt also nicht.

Grund: der Artikel hier von Christoph ist nie auf meinem Newsserver
angekommen (komisch, hatte ich noch nie).
Post by Christoph Purrucker
...
Post by Georges Heinesch
Was war es dann?
- ich habe geschrieben.
- das geschriebene wurde verifiziert (mittels PGP Signature Durchlauf).
- nach einige Zeit wurde gelesen und die Signature stimmte einfach nicht
mehr. Alles ohne Fehlermeldung.
Ja, dies erschüttert mein Weltbild. Die einzig mir schlüssige Erklärung
liegt darin, dass das RAM/CPU/Board defekt ist: Es wird jeweils eine
3-5GB große Datei geprüft und dabei kippt ein Bit aufm Bus/im RAM und
die Signatur stimmt nimmer. Das Problem ist ja, dass Du bei den vier
Dateien nicht weißt, ob immer das selbe gekippte Bit die Signatur
ungültig werden lässt.
Es kann doch nichts dergleichen sein, da ich nach dem Schreibvorgang die
Sig. gecheckt habe. Wenn es RAM, ... wäre, wären a. die Fehler nicht
immer reproduzierbar und b. teilweise auch andere Files betroffen. Ist
aber beides nicht der Fall. Der Controller gibt jetzt immer die gleichen
falschen Nutzdaten aus. Ich kann das auch mit Sicherheit sagen, da ich
nach der Entdeckung der Fehler, eine separate Signature der falschen
daten erstellt habe. Die ist immer korrekt, die falsche Signature immer
falsch!
Post by Christoph Purrucker
Hast Du das mehrfach reproduzieren können, dass immer die selben vier
Files kaputt sind? Reproduzierbar: Rechner aus - Hochfahren - eine
einzelne funktionierende Datei testen - runterfahren - hochfahren - eine
einzelne defekte Datei (mit möglichst gleicher Dateigröße) testen.
Absolut! Kein Zweifel in diesem Punkt!
Post by Christoph Purrucker
Du könntest auch eine Datei mehrfach (unter verschiedenen Namen) auf ne
andere Platte kopieren und dann binär vergleichen, ob irgendwo ein
kippendes Bit ist, oder die Daten immer gleich defekt von der
Quellplatte kommen. Alternativ kannst Du natürlich in einer Schleife
md5sum auf die Datei loslassen und schauen, ob auch nach Stunden immer
die selbe Summe rauskommt.
Diesen Fall kann ich mit der Signature der falschen Daten (siehe oben)
ausschliessen. Die Daten sind immer identisch falsch, i.e. die Signature
der falschen Daten stimmt immer!
Post by Christoph Purrucker
Cool wär jetzt natürlich, wenn Du ein Backup hättest, wo Du nachschauen
könntest, wie die Datei original aussah. Vielleicht ist ja viel mehr als
Bei Mp3 käme mir da etwa eine Playersoftware in den Sinn, die ungefragt
id3-Tags korrigiert...
Nicht sehr wahrscheinlich dass da einer rumgespielt hat.

Ich habe aber eine andere Idee. werde ich morgen wahrscheinlich machen. news:***@vo.lu

Was meinst du dazu?

Gruß,
--
Georges Heinesch
Mario 'BitKoenig' Holbe
2008-04-22 11:45:06 UTC
Permalink
Post by Georges Heinesch
Post by Rainer Zocholl
Post by Georges Heinesch
Merkt die Festplatte beim Schreiben bereits, dass der beschrieben
Sektor defekt ist oder muss dieser erst gelesen werden um den Defekt
festzustellen?^
Ja, natürlich.
Die Antwort von Rainer war zum einen etwas irrefuehrend und zum anderen
Post by Georges Heinesch
Post by Rainer Zocholl
Alle sectoren der Platte sind mit CRC prüfsummen gesichert.
"eigentlich" kann eine Platte nur heile Daten liefern oder gar keine.
Natuerlich kann man auf Deine "oder"-Frage korrekterweise mit "Ja"
antworten - auch wenn man nicht Informatiker ist, dann aber wohl aus
anderen Motiven :)

Die Antwort auf Deine Frage ist: Ja, natuerlich muss ein Sektor meistens
erst gelesen werden, im einen Defekt festzustellen. Aber beim Lesen
*wird* der Defekt festgestellt und es werden (mit hinreichender
Wahrscheinlichkeit) *keine* fehlerhaften Daten geliefert: Entweder die
Daten die Du bekommst sind sauber oder die Platte meldet Dir nen
Lesefehler.
Es gibt einige wenige Situationen in denen aktuelle Festplatten (die ja
i.d.R. kein read-after-write machen) auch Schreibfehler produzieren,
z.B. bei Sektoren von denen sie bereits wissen dass sie defekt sind, die
sie aber nicht reallokieren koennen. Ja, sowas gibts, Samsung
reallokiert (IMHO! - nur ein Ergebnis von Beobachtungen) z.B. keine
bereits reallokierten Sektoren (wenn ein Sektor aus dem Reserve-Areal
kaputt geht). Andere Platten koennen bestimmte Sektoren gar nicht
reallokieren.
Post by Georges Heinesch
Also liegt die Vermutung nahe dass die Fehler beim Schreiben entstanden
sind.
Oder nach dem Lesen - Bitkipper im RAM bspw. Letzteres laesst sich
leicht pruefen.
Post by Georges Heinesch
Post by Rainer Zocholl
Du hast in deimem PC probleme mit RAM oder Datenkabeln.
Nein. Nie. Keine Reboots oder sonstige Probleme.
Eine Erlangener Gruppe hat mal Untersuchungen zur Eskalationshaeufigkeit
von RAM-Bitkippern gemacht: Nur ein kleiner Teil fuehrt wirklich zu
Abstuerzen.
Post by Georges Heinesch
Diese Aussage lässt darauf schließen, dass Fehler auch im laufe der Zeit
entstehen können?
Klar. Festplatten basieren auf Magnetismus. Das ist ein Effekt der
sowohl zeitlich veraenderlich als auch anfaellig fuer
Umgebungsveraenderungen (Nachbarspur wird geschrieben,
Temperaturwechsel, etc.) ist.
Post by Georges Heinesch
Das mit dem "remappen" von schlechten Sektoren war mir auch nie richtig
verständlich. Du sagst dass dieses "remappen" nur vollzogen wird, wenn
es explizit vom User angestossen wird (wenn ich das richtig verstanden
habe)?
Das kommt drauf an. Die meisten Consumer-Festplatten heutzutage
reallokieren automatisch. Nur wenige SCSI-Platten brauchen noch einen
expliziten Anstoss und selbst da uebernimmt den i.d.R. der Treiber.
Das "Anstossen" hier hat einen anderen Grund: Natuerlich kann eine
Festplatte einen Sektor nicht reallokieren wenn der Fehler auffaellt, da
das ja gewoehnlich bei einem Lesevorgang der Fall ist. Wenn man da
reallokieren wuerde, waere der Sektor ja wieder lesbar und da wuerde
dann auf einmal irgendwas stehen (im guenstigsten Fall Nullen). Das
waere ein sehr unvorhersagbares Verhalten. Daher reallokieren
Festplatten Sektoren nur bei Schreibzugriffen. Wenn ein Lesevorgang
schiefgeht, merkt sich die Platte den Sektor zum reallokieren vor
(Stichwort: Current_Pending_Sectors) und fuehrt das dann beim naechsten
Schreibvorgang aus. Dazu muss man natuerlich erstmal auf den Sektor
schreiben - und das meinte Rainer vermutlich mit "anstossen".


regards
Mario
--
<Sique> Huch? 802.1q? Was sucht das denn hier? Wie kommt das ans TAGgeslicht?
Richard W. Könning
2008-04-22 23:43:06 UTC
Permalink
Post by Mario 'BitKoenig' Holbe
Das kommt drauf an. Die meisten Consumer-Festplatten heutzutage
reallokieren automatisch. Nur wenige SCSI-Platten brauchen noch einen
expliziten Anstoss und selbst da uebernimmt den i.d.R. der Treiber.
Das "Anstossen" hier hat einen anderen Grund: Natuerlich kann eine
Festplatte einen Sektor nicht reallokieren wenn der Fehler auffaellt, da
das ja gewoehnlich bei einem Lesevorgang der Fall ist. Wenn man da
reallokieren wuerde, waere der Sektor ja wieder lesbar und da wuerde
dann auf einmal irgendwas stehen (im guenstigsten Fall Nullen).
Wenn an der Stelle mein Kontostand steht, dann würde ich Nullen
keineswegs als den günstigsten Fall ansehen :-).
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Georges Heinesch
2008-04-25 08:29:26 UTC
Permalink
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.

Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.

Mache ich da keinen Denkfehler?

Gruß,
--
Georges Heinesch
Norbert Hahn
2008-04-25 10:05:42 UTC
Permalink
Post by Georges Heinesch
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.
Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.
Welchen RAID-Level?
Bei Spiegelung könnte die Idee funktionieren, wenn man einfach mal die
andere Platte ausliest. Aber bei RAID-5 wurde beim Auslesen der Datei
ja schon überprüft. Was steht in der Log-Datei dazu? Was zeigen die
SMART-Werte der einzelnen Platten?

Norbert
Georges Heinesch
2008-04-26 04:32:00 UTC
Permalink
Post by Norbert Hahn
Post by Georges Heinesch
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.
Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.
Welchen RAID-Level?
RAID-5
Post by Norbert Hahn
Aber bei RAID-5 wurde beim Auslesen der Datei
ja schon überprüft.
Geben die Parity meinst du? Nein, wird nicht gemacht.
Post by Norbert Hahn
Was steht in der Log-Datei dazu? Was zeigen die
SMART-Werte der einzelnen Platten?
Siehe Thread oben ...

Gruß,
--
Georges Heinesch
Norbert Hahn
2008-04-26 09:27:21 UTC
Permalink
Post by Norbert Hahn
Post by Norbert Hahn
Post by Georges Heinesch
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.
Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.
Welchen RAID-Level?
RAID-5
Wenn Du eine Platte aus dem Raid-5-Verbund heraus nimmst, wird sofort mit
dem Rebuild begonnen, sobald eine Platte hinzu kommt. Somit kannst Du genau
eine Platte testen. Ich weiß nicht ob der Controller so intelligent ist,
zu merken, wenn Du die vorher vorhandene Platte wieder hinzufügst, dass er
nichts tun muss.
Post by Norbert Hahn
Post by Norbert Hahn
Was steht in der Log-Datei dazu? Was zeigen die
SMART-Werte der einzelnen Platten?
Siehe Thread oben ...
Dann schalte das Raid ab, nimm die Platten einzeln heraus unter teste sie
am Plattencontroller Deines Rechners mit dem Programm des Plattenherstellers.

Norbert
Georges Heinesch
2008-04-26 17:53:31 UTC
Permalink
Post by Norbert Hahn
Post by Norbert Hahn
Post by Norbert Hahn
Post by Georges Heinesch
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert sind.
Alle Files haben eine PGP Signature. Kürzlich habe ich diese Signatures
verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.
Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.
Welchen RAID-Level?
RAID-5
Wenn Du eine Platte aus dem Raid-5-Verbund heraus nimmst, wird sofort mit
dem Rebuild begonnen, sobald eine Platte hinzu kommt.
Ich füge ja keine neue Platte hinzu. Ich nehme nur eine nach der anderen
aus den Verbund heraus, um zu testen ob es diese war die falsche
Nutzdaten liefert.
Post by Norbert Hahn
Somit kannst Du genau
eine Platte testen.
Genau. Die die ich gerade entfernt habe.
Post by Norbert Hahn
Ich weiß nicht ob der Controller so intelligent ist,
zu merken, wenn Du die vorher vorhandene Platte wieder hinzufügst, dass er
nichts tun muss.
Doch. So habe ich auch die Firmware auf den 4 Platten erneuert. Jeweils
eine Platte raus, an den onboard SATA Port, neue FW drauf und wieder in
den Verbund. Kein Rebuilt! BTW ... die Lesefahler existierten bereits
vor dem FW Update, nicht dass du jetzt meinst es hätte etwas damit zu tun.
Post by Norbert Hahn
Post by Norbert Hahn
Post by Norbert Hahn
Was steht in der Log-Datei dazu? Was zeigen die
SMART-Werte der einzelnen Platten?
Siehe Thread oben ...
Dann schalte das Raid ab, nimm die Platten einzeln heraus unter teste sie
am Plattencontroller Deines Rechners mit dem Programm des Plattenherstellers.
Sie SMART Daten sind perfekt! Mit der neuen HDD FW werden die nötigen
SMART Daten in der RAID Software (BIOS und Web Interface) angezeigt.

Gruß,
--
Georges Heinesch
Georges Heinesch
2008-04-28 17:20:42 UTC
Permalink
Post by Georges Heinesch
Post by Georges Heinesch
...
Ich habe zur Zeit eine Platte, auf der 3-5 GB große Files gelagert
sind. Alle Files haben eine PGP Signature. Kürzlich habe ich diese
Signatures verifiziert und 4 von #200 Files waren fehlerhaft.
Mir kam soeben eine Idee.
Wenn das RAID Daten ausgibt die fehlerhaft sind (die nach dem Schreiben
verifiziert wurden), so müsste es doch möglich sein, diese Daten
wiederzubekommen, wenn man nach und nach eine HDD nach der anderen
offline nimmt. Irgendwann würde dann die HDD offline sein, die die
fehlerhaften Daten ausgibt.
Mache ich da keinen Denkfehler?
Jein.

Prinzipiell denke ich immer noch dass das hier möglich gewesen wäre,
aber ich habe eine Tatsache des RAID übersehen.

Wenn ich die erste HDD aus dem Verbund nehme, muss ich darauf achten,
dass nicht mehr auf die verbliebenen 3 HDDs geschrieben wird. Praktisch
heißt das, dass ich kein OS (bei mir WinXP) starten darf, weil allein
der Bootvorgang schon etwas auf die das RaidSet schreibt, auch wenn der
User das nicht explizit tut.

Um die Daten jedoch von den 3 verbleibenden HDDs zu lesen, blieb mir
nichts anderes übrig. Ich musste das OS starten. Leider konnte ich
jedoch keine der 4 Files lesen. Die Signature war bei allen 4 Files
falsch. Kann jetzt sein dass ich nur Pech hatte. Andernfalls Denkfehler!

Als ich jetzt aber die abgesteckte HDD wieder dem RAID zur Verfügung
stellte, erkannte er diese als neuen HDD (klar, weil auf die anderen 3
HDDs geschrieben wurde, und auf diese nicht) und das rebuilt startete.

Somit konnte ich das sukzessive Testen der 4 Platten vergessen. Ich
hatte nur den Versuch mit einer HDD, da die Daten dieser nachher durch
das rebuilt zerstört wurden.

[
Um den Verbund überhaupt dem OS sichtbar zu machen, muss die Option
"Auto Activate Incomplete Raid" eingeschaltet sein, wenn eine Platte
fehlt (i.e. der Verbund nicht komplett ist). Sonst verweigert der RAID
Controller den Zugriff auf den Verbund. Gute Sache, um Inkonsistenzen zu
vermeiden!
]

Der Test hätte vermutlich funktioniert, wenn ich die HDDs mittels
Jumpers in einen read-only Zustand hätte versetzten können. Die HDDs
haben so etwas aber leider nicht.

Gruß,
--
Georges Heinesch
Lesen Sie weiter auf narkive:
Loading...