Festplatte defekt oder nur das Filesystem
Hallo, ich hatte bereits am letzten Sonntag geschrieben, dass ich Probleme mit meinem Filesystem nach einem Kernel-Update hatte. Glücklicherweise konnte ich das Filesystem (ext3) reparieren, und die Probleme mit einigen Programmen konnte ich durch Neuinstallation der betreffenden Pakete beheben. Leider gab es heute wieder Probleme mit dem Filesystem. Es war "nur" die Root-Partition mit ext3 betroffen. Ich bin wieder auf der Rettungskonsole gelandet, konnte e2fsck jedoch nicht starten. Das Programm gab nur eine Fehlermeldung von sich. In Knoppix konnte ich das Programm noch starten, aber es gab so extrem viele Probleme, sehr viele betroffende Dateien wurden aufgelistet und nach mehrmaligen Start von e2fsck hat mich das Programm immer noch gewarnt, dass Fehler auf der Partition seien, sodass ich mich für eine Neuinstallation (diesmal wieder SuSE 9.3, und siehe da, Skype funktioniert wieder ;-) ) entschieden habe. Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich? Würden dann nicht auch andere Partitionen betroffen sein? Wie kann ich das testen? MfG Kay
Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich? Würden dann nicht auch andere Partitionen
betroffen sein? Wie kann ich das testen?
MfG Kay
Hi Kay, Das kannst du testen, Drive Fitness Test (google) ist ein sehr gutes Tool um Festplatten zu testen. MfG jan
Hallo Kay, hallo Leute, Am Samstag, 17. Dezember 2005 00:27 schrieb Kay Patzwald:
ich hatte bereits am letzten Sonntag geschrieben, dass ich Probleme mit meinem Filesystem nach einem Kernel-Update hatte. [...] Leider gab es heute wieder Probleme mit dem Filesystem. [...] Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich?
Ich würde es nicht ausschließen - vor allem, da Du innerhalb kurzer Zeit mehrere Dateisystem-Fehler hattest.
Würden dann nicht auch andere Partitionen betroffen sein?
Kommt darauf an, welcher Bereich der Festplatte Probleme macht. Zumindest am Anfang ist aber oft nur eine Partition betroffen.
Wie kann ich das testen?
- Installation der smartmontools (Details siehe zugehörige Doku) - Test der Platte mit badblocks /dev/hdX Der von Jan genannte Drive Fitness Test ist AFAIK hersteller-spezifisch. Frag mich nicht, ob er auch Platten von der Konkurrenz testet ;-) - einen Versuch ist es jedenfalls wert. Ansonsten beim Hersteller Deiner Festplatte nach einem vergleichbaren Prüfprogramm suchen. Gruß Christian Boltz --
Du kannst niemals einer großen Panne entgehen, in dem Du eine kleine produzierst. Aber umgekehrt. Das nennt sich dann "Windows-Bugfix". [Sascha Wirth und Sebastian Weiser in dtk]
On Sat, 17 Dec 2005 01:04:38 +0100, Christian Boltz
Hallo Kay, hallo Leute,
Am Samstag, 17. Dezember 2005 00:27 schrieb Kay Patzwald:
ich hatte bereits am letzten Sonntag geschrieben, dass ich Probleme mit meinem Filesystem nach einem Kernel-Update hatte. [...] Leider gab es heute wieder Probleme mit dem Filesystem. [...] Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich?
Ich würde es nicht ausschließen - vor allem, da Du innerhalb kurzer Zeit mehrere Dateisystem-Fehler hattest.
Würden dann nicht auch andere Partitionen betroffen sein?
Kommt darauf an, welcher Bereich der Festplatte Probleme macht. Zumindest am Anfang ist aber oft nur eine Partition betroffen.
Wie kann ich das testen?
- Installation der smartmontools (Details siehe zugehörige Doku) - Test der Platte mit badblocks /dev/hdX
Der von Jan genannte Drive Fitness Test ist AFAIK hersteller-spezifisch. Frag mich nicht, ob er auch Platten von der Konkurrenz testet ;-) - einen Versuch ist es jedenfalls wert. Ansonsten beim Hersteller Deiner Festplatte nach einem vergleichbaren Prüfprogramm suchen.
Gibt es ne Möglichkeit den Hersteller herauszufinden, ohne den Laptop aufschrauben zu müssen? Die Platte wird ja wahrscheinlich nicht von Acer selbst sein. Habe einen Acer TM 661. MfG Kay
Am Samstag, 17. Dezember 2005 00:27 schrieb Kay Patzwald:
Gibt es ne Möglichkeit den Hersteller herauszufinden, ohne den Laptop aufschrauben zu müssen? Die Platte wird ja wahrscheinlich nicht von Acer selbst sein. Habe einen Acer TM 661.
Wenn ich mich recht erinnere zeigt es der Rechner entweder beim booten, im Bios oder smartmon zeigt es. Gruß Johannes -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
Hallo, kleiner Nachtrag.
Am Samstag, 17. Dezember 2005 00:27 schrieb Kay Patzwald:
Gibt es ne Möglichkeit den Hersteller herauszufinden, ohne den Laptop aufschrauben zu müssen? Die Platte wird ja wahrscheinlich nicht von Acer
selbst sein. Habe einen Acer TM 661.
Wenn ich mich recht erinnere zeigt es der Rechner entweder beim booten, im Bios oder smartmon zeigt es.
In der boot.msg steht es auch drin. Gruß Johannes -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
Hallo, kleiner Nachtrag.
Am Samstag, 17. Dezember 2005 00:27 schrieb Kay Patzwald:
Gibt es ne Möglichkeit den Hersteller herauszufinden, ohne den Laptop aufschrauben zu müssen? Die Platte wird ja wahrscheinlich nicht von Acer
selbst sein. Habe einen Acer TM 661.
Hallo Kay, DriveFitness test verrät es dir sonst auch :) Acer hatte in der 660 Serie meines Wissens nach Hitachi Festplatten verbaut. Mfg Jan
* Kay Patzwald wrote on Sat, Dec 17, 2005 at 00:27 +0100:
ich hatte bereits am letzten Sonntag geschrieben, dass ich Probleme mit meinem Filesystem nach einem Kernel-Update hatte.
(Nur mal am Rande: Speicher und CPU Fehler sorgen auch für herrliche Filesystem-Fehler.) Gut, also Backup haste gerade gemacht, ja? :-)
Leider gab es heute wieder Probleme mit dem Filesystem. Es war "nur" die Root-Partition mit ext3 betroffen. Ich bin wieder auf der Rettungskonsole gelandet, konnte e2fsck jedoch nicht starten. Das Programm gab nur eine Fehlermeldung von sich.
Eine also nur... (WELCHE wäre evtl. hilfreicher ;)) [...]
Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich?
(Was sind denn das für Fragen?!) Ja, Festplatten gehen von Zeit zu Zeit kaputt.
Würden dann nicht auch andere Partitionen betroffen sein?
Möglicherweise, aber nicht zwingend. Selbst wenn Bereiche kaputt sind, können diese beispielsweise ungenutzt sein. Oder gehen nächste Woche kaputt (Wenn es Plattenfehler sind, merkt man die ja erst, wenn die HDD HotFix voll ist, und dann ist schon so viel kaputt, dass bald noch mehr kommt).
Wie kann ich das testen?
Was sagte syslog? Gab's da Meldungen über IDE Timeouts oder sector I/O errors? drive unit errors oder sowas? S.M.A.R.T sollte laut Marketing helfen, aber meine letzte Platte ist mit SMART OK gestorben (nach einer zwei Wöchigen Agonie)... "badblocks" hat IMHO den Nachteil, dass man nicht sieht, welche Blöcke kaputt waren und von der Platte gemappt wurden. Das sollte man theoretisch über SMART auslesen können. Praktisch ist vermutlich immer alles OK... Beim mkfs ist ein -c natürlich trozdem immer eine Gute Idee. Kann yast vermutlich auch irgendwie, sonst beim nächsten Mal F1-Shell :-) Ja, mal paar Stunden Testtools oder Scripte drüber jagen, wenn dann die Platte kaputt ist, hatte sie einen Schlag weg, sonst log angucken :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Sat, 17 Dec 2005 03:16:51 +0100, Steffen Dettmer
* Kay Patzwald wrote on Sat, Dec 17, 2005 at 00:27 +0100:
ich hatte bereits am letzten Sonntag geschrieben, dass ich Probleme mit meinem Filesystem nach einem Kernel-Update hatte.
(Nur mal am Rande: Speicher und CPU Fehler sorgen auch für herrliche Filesystem-Fehler.)
Gut, also Backup haste gerade gemacht, ja? :-)
Backups habe ich. :-)
Leider gab es heute wieder Probleme mit dem Filesystem. Es war "nur" die Root-Partition mit ext3 betroffen. Ich bin wieder auf der Rettungskonsole gelandet, konnte e2fsck jedoch nicht starten. Das Programm gab nur eine Fehlermeldung von sich.
Eine also nur... (WELCHE wäre evtl. hilfreicher ;))
Das Programm konnte auf irgendeine Bibliothek nicht zugreifen, vermutlich, weil diese ebenfalls betroffen war. Welche kann ich leider nicht sagen.
[...]
Nen Bekannter meinte nun aber, dass evtl. die Festplatte defekt sein könnte. Wäre das möglich?
(Was sind denn das für Fragen?!)
Wieso? Ist eine Frage nach dem kausalen Zusammenhang. Ich hatte noch keine defekte Festplatte und weiß so leider nicht, wie sich das äußert.
Ja, Festplatten gehen von Zeit zu Zeit kaputt.
Interessant. ;-)
Würden dann nicht auch andere Partitionen betroffen sein?
Möglicherweise, aber nicht zwingend. Selbst wenn Bereiche kaputt sind, können diese beispielsweise ungenutzt sein. Oder gehen nächste Woche kaputt (Wenn es Plattenfehler sind, merkt man die ja erst, wenn die HDD HotFix voll ist, und dann ist schon so viel kaputt, dass bald noch mehr kommt).
Wie kann ich das testen?
Was sagte syslog? Gab's da Meldungen über IDE Timeouts oder sector I/O errors? drive unit errors oder sowas?
Nach der Neuinstallation noch nicht.
S.M.A.R.T sollte laut Marketing helfen, aber meine letzte Platte ist mit SMART OK gestorben (nach einer zwei Wöchigen Agonie)...
"badblocks" hat IMHO den Nachteil, dass man nicht sieht, welche Blöcke kaputt waren und von der Platte gemappt wurden. Das sollte man theoretisch über SMART auslesen können. Praktisch ist vermutlich immer alles OK...
Beim mkfs ist ein -c natürlich trozdem immer eine Gute Idee. Kann yast vermutlich auch irgendwie, sonst beim nächsten Mal F1-Shell :-)
Ja, mal paar Stunden Testtools oder Scripte drüber jagen, wenn dann die Platte kaputt ist, hatte sie einen Schlag weg, sonst log angucken :)
Danke für die Tipps. Werde ich mal testen. MfG Kay
Am Samstag, 17. Dezember 2005 03:16 schrieb Steffen Dettmer:
(...). S.M.A.R.T sollte laut Marketing helfen, aber meine letzte Platte ist mit SMART OK gestorben (nach einer zwei Wöchigen Agonie)... (...).
SMART besteht ja nicht nur aus dem Monitoring. Meine IBM-Platten erfreuen sich laut SMART und Drive-Fitness-Test auch noch bester Gesundheit, falls das BIOS sie mal findet! Man sollte auf die Werte "Reallocated_Sector_Ct" und "UDMA_CRC_Error_Count" achten. Wenn die größer als 0 sind mach ich mir Sorgen. "smartctl -l error /dev/hda" zeigt das interne Fehler-Log an, sollte auch besser leer sein. Und man kann Platten recht einfach und effektiv mit "smartctl -t long /dev/hda" testen (das dauert auch tatsächlich lange, siehe "smartctl -c /dev/hda"). "smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an (IMHO macht der Drive-Fitness-Test auch nichts anderes als so einen Selbsttest, jedenfalls finde ich dessen Tests in diesem Log). Es gibt je nach Platte auch noch andere Logs, siehe Ende der Ausgabe von "smartctl -a /dev/hda" HTH Jan -- Real Users never know what they want, but they always know when your program doesn't deliver it.
* Jan Ritzerfeld wrote on Sat, Dec 17, 2005 at 18:12 +0100:
Am Samstag, 17. Dezember 2005 03:16 schrieb Steffen Dettmer:
(...). S.M.A.R.T sollte laut Marketing helfen, aber meine letzte Platte ist mit SMART OK gestorben (nach einer zwei Wöchigen Agonie)... (...).
SMART besteht ja nicht nur aus dem Monitoring. Meine IBM-Platten erfreuen sich laut SMART und Drive-Fitness-Test auch noch bester Gesundheit, falls das BIOS sie mal findet!
Na ja, oder die ATA Kontroller (in den Platten) nicht "starten", weil sie ein Problem haben - was u.U. sporadisch ist. Sieht so aus, als ob die Platte "öfter mal nicht da ist", aber eigentlich ist sie einfach kaputt. Sollte ja mit SMART eigentlich nicht (mehr) passieren, aber da Windows nicht drauf angewiesen ist, würde ich nicht unbedingt mit einer guten (sondern mit einer billigen) SMART-Implementierung rechnen.
Man sollte auf die Werte "Reallocated_Sector_Ct" und "UDMA_CRC_Error_Count" achten. Wenn die größer als 0 sind mach ich mir Sorgen. "smartctl -l error /dev/hda" zeigt das interne Fehler-Log an, sollte auch besser leer sein.
Bei der einen "langsam und gleichmässig sterbenden" Platte, die ich damals hatte (ne IBM irgendwas, aber das hat nix zu sagen; vielleicht ist IBM schlecht, andere aber nicht unbedingt besser!), war nix mit Smart-Problemen... Hatte ich damals auch von anderen gehört, dass das wohl alles mögliche aber nicht zuverlässig ist...
Und man kann Platten recht einfach und effektiv mit "smartctl -t long /dev/hda" testen (das dauert auch tatsächlich lange, siehe "smartctl -c /dev/hda").
/Falls/ man denn zufällig eine Platte hat, die das richtig macht. Probleme reichen von "geht sofort nicht mehr" über "hängt hin und wieder" bis zu "knallt irgendwann spontan weg", weiss nicht, woran das nu wieder liegt, vielleicht, wenn gerade der zu testende Sektor gelesen wird, durch drei teilbar ist und der letzte Sektor gerade war oder was weiss ich. Ich persönlich halte von SMART also nicht sooo viel, kann aber natürlich Zufall sein. Ganz früher hatte ich es mal probiert (SuSE aktivierte SMART nicht automatisch, "wegen vieler Probleme" oder so), ging gar nicht. Später hab ich mit neuerer Hardware nochmal gespielt und zwar auf meinem Privat-Server mit verschiedenen Platten - und verschiedene Resultate bekommen (inkl. solchen, die ein Reboot erforderten, weil es "hing"). Dabei hab ich rumgespielt, um zu gucken, "obs wirklich geht". DMA an, aus, lesen hier, schreiben da, hdparm -t/-T zwischendurch, selftest, ... alles, was mir so einfiel. Seit einem dieser Abstürze hat die eine Platte Fehlereinträge, in der Form von:
Timestamp is seconds since the previous disk power-on. Note: timestamp "wraps" after 2^32 msec = 49.710 days.
Error 6 occurred at disk power-on lifetime: 513 hours When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER:04 SC:01 SN:00 CL:4f CH:c2 D/H:f0 ST:51 Sequence of commands leading to the command that caused the error were: DCR FR SC SN CL CH D/H CR Timestamp 00 d0 01 00 4f c2 f0 b0 71.813 00 02 00 00 00 00 f0 ef 25.500 00 00 10 00 00 00 f0 c6 25.500 00 00 00 00 00 00 f0 f8 25.500 00 00 3f 00 00 00 b0 10 25.500
muss zugeben, dass mir das überhaupt nichts sagt :-) Jetzt läuft ein smartd aber (mit /dev/hd[ab] -a -m <addr>) stabil (soweit man das bei einem gelangweilten Server, der eh fast monatlich gebootet wird, sagen kann). Schlimmstenfalls kommt halt wieder keine Warnung, denke ich... :)
"smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an
Hast Du da mehr als einen Eintrag? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am Samstag, 17. Dezember 2005 23:29 schrieb Steffen Dettmer:
* Jan Ritzerfeld wrote on Sat, Dec 17, 2005 at 18:12 +0100: (...).
SMART besteht ja nicht nur aus dem Monitoring. Meine IBM-Platten erfreuen sich laut SMART und Drive-Fitness-Test auch noch bester Gesundheit, falls das BIOS sie mal findet!
Na ja, oder die ATA Kontroller (in den Platten) nicht "starten", weil sie ein Problem haben - was u.U. sporadisch ist. Sieht so aus, als ob die Platte "öfter mal nicht da ist", aber eigentlich ist sie einfach kaputt. Sollte ja mit SMART eigentlich nicht (mehr) passieren, aber da Windows nicht drauf angewiesen ist, würde ich nicht unbedingt mit einer guten (sondern mit einer billigen) SMART-Implementierung rechnen.
Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools. Interessant ist höchstens noch dftview, damit kann man die Logs, welcher der DFT auf eine eingelegte Floppy schreibt aufschlüssen.
Man sollte auf die Werte "Reallocated_Sector_Ct" und "UDMA_CRC_Error_Count" achten. Wenn die größer als 0 sind mach ich mir Sorgen. "smartctl -l error /dev/hda" zeigt das interne Fehler-Log an, sollte auch besser leer sein.
Bei der einen "langsam und gleichmässig sterbenden" Platte, die ich damals hatte (ne IBM irgendwas, aber das hat nix zu sagen; vielleicht ist IBM schlecht, andere aber nicht unbedingt besser!), war nix mit Smart-Problemen... Hatte ich damals auch von anderen gehört, dass das wohl alles mögliche aber nicht zuverlässig ist...
Es gilt schon prinzipiell nur diese Richtung: SMART sagt kaputt -> die Platte ist wohl kaputt Eine Anekdote aus den letzten Wochen: Lernpartner hat seinen PC umgebaut und eine Platte im Wechselramen mit einem 40-poligen IDE-Kabel angeschlossen. Naja, im Log fanden sich dann natürlich die typischen Platte-liegt-im-Sterben-DMA-Fehlermeldungen. Fehlerlog der Platte sah das ähnlich, aber "UDMA_CRC_Error_Count" war recht hoch, "Reallocated_Sector_Ct" aber 0. Also mal "smartctl -t long ..." drauf losgelassen. Da man gerade schonmal dabei war auch die anderen Platten mit smartmontools betrachtet. Huch, hda hatte vor einigen Monaten(sic!) auch DMA-Fehler! Also auch mal "smartctl -t long /dev/hda" laufen lassen. Und bei dieser Seagate-Platte war der Test ehrlich, unter Angabe des LBA fand man einen Fehler im Selbsttest-Log, "Reallocated_Sector_Ct" stand auf 2. Sprich, SMART ist genauso nützlich wie jeder andere Test auch. Wenn der Test erfolgreich ist (d. h. es wurde ein Fehler gefunden), dann weiß man, daß das Testobjekt fehlerhaft ist, ansonsten ist man aber keinen Deut schlauer als vorher.
(...). Seit einem dieser Abstürze hat die eine Platte Fehlereinträge, in der
Form von:
Timestamp is seconds since the previous disk power-on. Note: timestamp "wraps" after 2^32 msec = 49.710 days.
Error 6 occurred at disk power-on lifetime: 513 hours When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER:04 SC:01 SN:00 CL:4f CH:c2 D/H:f0 ST:51 Sequence of commands leading to the command that caused the error were: DCR FR SC SN CL CH D/H CR Timestamp 00 d0 01 00 4f c2 f0 b0 71.813 00 02 00 00 00 00 f0 ef 25.500 00 00 10 00 00 00 f0 c6 25.500 00 00 00 00 00 00 f0 f8 25.500 00 00 3f 00 00 00 b0 10 25.500
muss zugeben, dass mir das überhaupt nichts sagt :-)
Hmm. Bei der Augabe von meinem smartctl ist da noch eine Spalte "Command/Feature_Name". Ich hab einen Log-Eintrag von meinem Versuch den Write-Cache auszuschalten: Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 01 00 00 a0 Error: ABRT CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- b1 c0 00 01 00 00 a0 00 00:00:06.063 DEVICE CONFIGURATION RESTORE ef 03 0c 01 00 00 a0 00 00:00:06.063 SET FEATURES [Set transfer mode] ec 00 03 01 00 00 a0 00 00:00:06.063 IDENTIFY DEVICE 91 00 3f 01 00 00 af 00 00:00:06.063 INITIALIZE DEVICE PARAMETERS [OBS-6] 10 00 00 01 00 00 a0 00 00:00:06.063 RECALIBRATE [OBS-4]
(...).
"smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an
Hast Du da mehr als einen Eintrag?
Ja, pro Selbsttest einen. Bei meiner kaputten IBM also 6 Stück oder so. Natürlich alle ohne Fehler. X-) Gruß Jan -- If it weren't for the last minute, nothing would get done.
Jan Ritzerfeld wrote:
[...] Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools.
Das stimmt definitiv nicht. Sowohl DFT (urspruenglich von IBM) als auch PowerMax (Maxtor) machen bei ihren ausfuehrlichen Tests zumindest einen Leseversuch aller Sektoren, IIRC kann man theoretisch sogar Schreib- und Leseversuche machen, aber das natuerlich nur mit Datenverlust. Im Gegensatz zu den Standardeinstellungen der smartmontools (nur monitoring) sind diese Programme aktive Tools (aehnlich wie badblocks), d.h. sie lesen nicht nur die SMART-Daten der Platte aus (deswegen geht ein ausfuehrlicher Test mit PowerMax bei Platten mit 300GB oder groesser z.B. auch mal mehrere Stunden). Sie entdecken meiner Erfahrung nach zuverlaessig Fehler einer Platte (und fuer Garantieabwicklung wird der Error Code, den diese Programme generieren, i.d.R. sowieso gebraucht) - die smartmontools haben mich da schon oefters im Stich gelassen und selbst bei heftig kaputter Platte (Ansteuerung fehlerhaft, Klackgeraeusche) noch immer behauptet, alles sei in Ordnung. Siehe auch meine Emails von vor ein paar Wochen bzw. Monaten. Die genannten Tools funktionieren allerdings normalerweise nur mit den Platten des jeweiligen Herstellers, es sind keine allgemeinen Programme, die man mit jeder beliebigen Festplatte anwenden kann. CU, Th.
Am Dienstag, 20. Dezember 2005 00:19 schrieb Thomas Hertweck:
Jan Ritzerfeld wrote:
[...] Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools.
Das stimmt definitiv nicht. Sowohl DFT (urspruenglich von IBM) als auch PowerMax (Maxtor) machen bei ihren ausfuehrlichen Tests zumindest einen Leseversuch aller Sektoren, IIRC kann man theoretisch sogar Schreib- und Leseversuche machen, aber das natuerlich nur mit Datenverlust. Im Gegensatz zu den Standardeinstellungen der smartmontools (nur monitoring) sind diese Programme aktive Tools (aehnlich wie badblocks), d.h. sie lesen nicht nur die SMART-Daten der Platte aus (deswegen geht ein ausfuehrlicher Test mit PowerMax bei Platten mit 300GB oder groesser z.B. auch mal mehrere Stunden).
Also ich denke, daß ich das ausführlich genug in den vorherigen Postings erklärt habe, Stichwort "smartctl -t long ...". Ich bezog mich nicht auf die Standardeinstellungen der smartmontools, sondern auf das explizite Testen der Platten.
Sie entdecken meiner Erfahrung nach zuverlaessig Fehler einer Platte (und fuer Garantieabwicklung wird der Error Code, den diese Programme generieren, i.d.R. sowieso gebraucht) -
Das steht im Gegensatz zu meinen Erfahrungen mit dem DFT, welcher genauso blind wie "smartctl -t long ..." war -> nix mit error code, angeblich war alles in Ordnung.
die smartmontools haben mich da schon oefters im Stich gelassen und selbst bei heftig kaputter Platte (Ansteuerung fehlerhaft, Klackgeraeusche) noch immer behauptet, alles sei in Ordnung.
Wie ich schon geschrieben habe, bei den Deathstar-Platten sehe ich das absolut genauso. Laut SMART und(sic!) DFT alles toll, aber das BIOS findet die Platten halt recht selten.
Siehe auch meine Emails von vor ein paar Wochen bzw. Monaten. Die genannten Tools funktionieren allerdings normalerweise nur mit den Platten des jeweiligen Herstellers, es sind keine allgemeinen Programme, die man mit jeder beliebigen Festplatte anwenden kann.
Ich persönlich hatte bei meine drei oder vier defekten Deathstar-Platten nie das Glück, daß der DFT der Meinung war, daß die Platten defekt wären. Das hielt sie nicht davon ab, mit DMA-Fehlern im syslog um sich zu schmeißen und sich letztlich vorm BIOS zu verstecken, und selbst dann waren sie laut DFT vollkommen in Ordnung. Gruß Jan -- There are two reasons for doing things, a very good reason and the real reason.
Hallo, Am Tue, 20 Dec 2005, Jan Ritzerfeld schrieb: [..]
Wie ich schon geschrieben habe, bei den Deathstar-Platten sehe ich das absolut genauso. Laut SMART und(sic!) DFT alles toll, aber das BIOS findet die Platten halt recht selten.
Aeh, du hast aber schon die DMA-Einstellungen und die Kabel geprueft? Kabel laenger als 45 cm sind tabu (und das sind viele Kabel!) und fuer UDMA 66 / 100 und 133 muessen es 80adrige Kabel sein! Gerade dass das BIOS die Platten manchmal, aber nicht immer, findet schreit geradezu "falsches Kabel" oder Wackelkontakt o.ae. Kann aber natuerlich sein, dass auch die HDDs einen weg haben, aber bei solchen Problemen (auch die DMA-Fehlermeldungen im log) eher o.g. Fehler. -dnh -- 150: SETI Es gibt sicher extraerrestrische Wesen. Daß keine bis jetzt mit Menschen in Kontakt getreten sind, beweist deren Intelligenz. (Michael Sohmen)
Am Dienstag, 20. Dezember 2005 03:22 schrieb David Haller:
(...). Kann aber natuerlich sein, dass auch die HDDs einen weg haben, aber bei solchen Problemen (auch die DMA-Fehlermeldungen im log) eher o.g. Fehler.
Die Platten hatten einen weg. Gaben auch interessante Geräusche von sich. Google einfach mal nach IBM Deathstar. :) Gruß Jan -- What's the difference between marriage and a gun? -- - The gun is faster.
* Jan Ritzerfeld wrote on Mon, Dec 19, 2005 at 22:38 +0100:
Am Samstag, 17. Dezember 2005 23:29 schrieb Steffen Dettmer:
[...]
würde ich nicht unbedingt mit einer guten (sondern mit einer billigen) SMART-Implementierung rechnen.
Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools. Interessant ist höchstens noch dftview, damit kann man die Logs, welcher der DFT auf eine eingelegte Floppy schreibt aufschlüssen.
Selbst wenn man von "aussen" alle Sektoren liest und schreibt (letzteres geht i.d.R. schon ohne Datenverlust, man kann ja lesen, schreiben, restaurieren), weiss man noch lange nicht, was sich denn die Plattenfirmware nu genau denkt. Würde mich ja mal interessieren, wie gross so ne Plattenfirmware eigentlich ist. Wäre nicht überrascht, wäre es ein komplexes Stück Software (mit den naturgemäss zahlreich vorhandenen Bugs). Gaaaanz früher - ich glaub bei MFM Platten - gabs Tools, die haben jeden Sektor mehrfach gelesen, die Sektor-Prüfdaten (wie auch immer die korrekt heissen) geprüft (die man heute meines Wissens nach überhaupt nicht mehr aus einer Platte rauskriegt). Klar ist, dass moderne IDE Platten sonstwas am Bus vorgaugeln, z.B. es gäbe 255 Köpfe und jeder Track hätte gleichviel Sektoren (obwohl innen ja weniger sind) usw. Irgendwie wirkt daher ein "Test von aussen" etwa so, als ob ich Motorabnutzung "messe", in den ich probiere, ob das Auto noch von Hamburg nach München fahren kann. Kommt es an, weiss ich nicht, ob der Motor kurz vor dem Tot ist, das Öl auf "Minimal" steht und das Auto vielleicht in Berlin in einer Werkstatt war (gut, ein Blick ins Wartungs-("Smart")-Scheckheft sollte einen reallocate-Eintrag haben, FALLS denn das Scheckheft überhaupt gepflegt wird)...
Bei der einen "langsam und gleichmässig sterbenden" Platte, die ich damals hatte (ne IBM irgendwas, aber das hat nix zu sagen; vielleicht ist IBM schlecht, andere aber nicht unbedingt besser!), war nix mit Smart-Problemen... Hatte ich damals auch von anderen gehört, dass das wohl alles mögliche aber nicht zuverlässig ist...
Es gilt schon prinzipiell nur diese Richtung: SMART sagt kaputt -> die Platte ist wohl kaputt
In der Praxis sagt SMART vermutlich meistens gar nichts, weil die Platten gar nicht mehr antworten :) Weiss nicht, vielleicht spielen da auch Gewährleistungsgründe ne Rolle. Hat eine Platte Fehlereinträge etc., könnte ich sie ja tauschen wollen. Überzeugenden Gerüchten zufolge haben Platte eh /immer/ Fehler, weil das eine Staubkorn pro Kubikmeter irgendwo dann doch ein Loch geschlagen hat, diese aber automatisch reallokiert werden, so dass man es nicht sieht. Früher waren Aufkleber mit der "defect block list" drauf, heute ist das in Software versteckt. Aber der gleiche Fakt. Schon alleine, dass man diese im SMART nicht sieht, zeigt ja, dass SMART "lügt". So kann man nicht einschätzen, ob man orginal 5 kaputte Sektoren (gute Platte) oder 50 (schlechte Platte - Zahlen geraten) hatte. Vermutlich eher 50, weil die mit 5 vermutlich ein SCSI Interface bekommen haben, um überhaupt irgendein Argument zu haben, warum Platten mit solchen Kontrollern plötzlich deutlich teuerer sind (und noch teurer, wenn links und rechts ein Spannungspin am Stecker mit dran ist - sicherlich liegt der Preisunterschied nicht am Stecker selbst ;)).
Eine Anekdote aus den letzten Wochen: Lernpartner hat seinen PC umgebaut und eine Platte im Wechselramen mit einem 40-poligen IDE-Kabel angeschlossen. Naja, im Log fanden sich dann natürlich die typischen Platte-liegt-im-Sterben-DMA-Fehlermeldungen. Fehlerlog der Platte sah das ähnlich, aber "UDMA_CRC_Error_Count" war recht hoch,
Da gibt's also mindestens eine SMART-Implementierung, die etwas tut :)
"Reallocated_Sector_Ct" aber 0. Also mal "smartctl -t long ..." drauf losgelassen. Da man gerade schonmal dabei war auch die anderen Platten mit smartmontools betrachtet. Huch, hda hatte vor einigen Monaten(sic!) auch DMA-Fehler! Also auch mal "smartctl -t long /dev/hda" laufen lassen. Und bei dieser Seagate-Platte war der Test ehrlich, unter Angabe des LBA fand man einen Fehler im Selbsttest-Log, "Reallocated_Sector_Ct" stand auf 2.
Wobei man nicht mal genau weiss, was das wirklich heisst. Vielleicht ist der zweite Chunk je von 1 MB grossen Hotfixes voll, nachdem 8 Sets von 255*512 Byte grossen fehlerhaften "Blöcken" an verschiedenen Stellen relokiert wurde. (Alles ausgedacht). Da es für Kunden sicherlich besser aussieht, wenn bei SMART nix kommt, und Firmen ja es für die Kunden immer besser aussehen lassen wollen, liegt der Verdacht nahe (und zeigt meine minimale persönliche Erfahrung), dass bei SMART halt (fast) nix kommt. Ist ne Platte wirklich kaputt, ist's nämlich eh egal.
Sprich, SMART ist genauso nützlich wie jeder andere Test auch.
Oder wie Studien. Da kann man sich über den Sponsor auch aussuchen, was bei rauskommen soll :-)
Wenn der Test erfolgreich ist (d. h. es wurde ein Fehler gefunden), dann weiß man, daß das Testobjekt fehlerhaft ist, ansonsten ist man aber keinen Deut schlauer als vorher.
Ja, Du willst auf die "logische" Limitierung ("Testen kann man nur die Anwesenheit von Fehlern, nicht deren Abwesenheit"), hinaus, die natürlich vollkommen richtig und eh immer da ist - aber ich denke, SMART ist längst nicht so gut/genau/ehrlich.
00 00 3f 00 00 00 b0 10 25.500
muss zugeben, dass mir das überhaupt nichts sagt :-)
Hmm. Bei der Augabe von meinem smartctl ist da noch eine Spalte "Command/Feature_Name".
Gut, mein tool ist sicherlich etwas ältlich ;)
Ich hab einen Log-Eintrag von meinem Versuch den Write-Cache auszuschalten:
(auch so ein Ding, warum geht das nicht absolut immer? Vielleicht geht es ja NIE, aber manche Platten melden den Fehler bloss nicht :))
After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 01 00 00 a0 Error: ABRT
<sarkasmus> Ahh! Error ABRT! Alles klar! Bei ABRT ist ja klar, dass der Write Cache nicht abgeschaltet werden konnte, weil der Fehler ABRT auftrat. Schon toll, dass SMART :-) </sarkasmus>
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- b1 c0 00 01 00 00 a0 00 00:00:06.063 DEVICE CONFIGURATION RESTORE ef 03 0c 01 00 00 a0 00 00:00:06.063 SET FEATURES [Set transfer mode]
"Set transfer mode" war vorher? Oder hat es tatsächlich etwas mit Setting cache mode zu tun? Kann ja sein, dass in irgendeinem IDE Standard sowas steht, hab da NULL Ahnung, aber klingt zumindestens nicht wirklich hilfreich. Aber vielleicht kann ja ein Profi an diesen Informationen tatsächlich erkennen, welcher Fehler beim "Write-Cache-Abschalten" auftrat. Ich würde jedenfalls ein Log in der Form von: After command completion occurred, registers were: ER: 04 FEATURE_NOT_AVAILABLE ST: 51 OPTIONAL_IDE_FEATURE_NOT_IMPLEMENTED SC: 00 NON_FATAL_CONTINUE SN: 01 ERROR_SUCCESSFULLY_LOGGED usw. (alles ausgedacht) CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- b1 c0 00 01 00 00 a0 00 00:00:06.063 IDE_EXT_READ_CAPABILITIES ef 03 0c 01 00 00 a0 00 00:00:06.063 IDE_EXT_READ_CAPABILITIES_OK ec 00 03 01 00 00 a0 00 00:00:06.063 IDE_CNF_SET_CACHE_MORE_READ 10 00 00 01 00 00 a0 00 00:00:06.063 FEATURE_NOT_AVAILABLE usw. (alles ausgedacht - wie immer, ihr kennt das von mir :-) )
(...).
"smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an
Hast Du da mehr als einen Eintrag?
Ja, pro Selbsttest einen. Bei meiner kaputten IBM also 6 Stück oder so.
Ich hab auf zwei verschiedenen Platten genau einen Eintrag (wie auch immer der da reingekommen ist), obwohl schon mehrmals smartctl -t etc. gemacht. Vielleicht ist der Eintrag hardcoded, damit (halb-)schlaue monitortools "ihrern" Testversuch immer "sehen" und nicht warnen, dass SMART "komisch" ist :-)
Natürlich alle ohne Fehler. X-)
Muss dann wohl am Kabel liegen :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am Dienstag, 20. Dezember 2005 20:07 schrieb Steffen Dettmer:
* Jan Ritzerfeld wrote on Mon, Dec 19, 2005 at 22:38 +0100:
Am Samstag, 17. Dezember 2005 23:29 schrieb Steffen Dettmer:
[...]
würde ich nicht unbedingt mit einer guten (sondern mit einer billigen) SMART-Implementierung rechnen.
Wenn es nur das wäre, der Drive-Fitness-Test scheint keinen Deut besser zu sein, bzw. sich auf die SMART-Implementierung der Platten zu verlassen. So ein Tool kann man sich unter dann auch gleich sparen, da hat man ja smartmontools. Interessant ist höchstens noch dftview, damit kann man die Logs, welcher der DFT auf eine eingelegte Floppy schreibt aufschlüssen.
Selbst wenn man von "aussen" alle Sektoren liest und schreibt (letzteres geht i.d.R. schon ohne Datenverlust, man kann ja lesen, schreiben, restaurieren), weiss man noch lange nicht, was sich denn die Plattenfirmware nu genau denkt.
Eben. Die mappt eh fleißig defekte Sektoren um. Und von diese Reservesektoren gibt es wohl ne ganze Menge. Richtig paranoid ist ja IIRC die Man-Page zu wipe.
Würde mich ja mal interessieren, wie gross so ne Plattenfirmware eigentlich ist.
Gute Frage, der gesamte Installer ist natürlich riesig: http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-43972
Wäre nicht überrascht, wäre es ein komplexes Stück Software (mit den naturgemäss zahlreich vorhandenen Bugs).
Hehe, sowas: http://www.heise.de/security/artikel/60711/0 ? Trotzdem sehe ich die Plattenfirmware als noch relativ fehlerfrei an, normale Applikationen stürzen deutlich häufiger ab. Gut, Autos werden auch immer buganfälliger, aber im Vergleich zu "normaler" Software geht das ja noch.
Gaaaanz früher - ich glaub bei MFM Platten -
So wie die Floppys für den C64 und den Amiga? :)
gabs Tools, die haben jeden Sektor mehrfach gelesen, die Sektor-Prüfdaten (wie auch immer die korrekt heissen) geprüft (die man heute meines Wissens nach überhaupt nicht mehr aus einer Platte rauskriegt). (...).
Das wird echt schon lang her sein, oder? Also vor SCSI-Bus-Platten.
Irgendwie wirkt daher ein "Test von aussen" etwa so, als ob ich Motorabnutzung "messe", in den ich probiere, ob das Auto noch von Hamburg nach München fahren kann. Kommt es an, weiss ich nicht, ob der Motor kurz vor dem Tot ist, das Öl auf "Minimal" steht und das Auto vielleicht in Berlin in einer Werkstatt war (gut, ein Blick ins Wartungs-("Smart")-Scheckheft sollte einen reallocate-Eintrag haben, FALLS denn das Scheckheft überhaupt gepflegt wird)...
So ähnlich sehe ich das auch. Daher rate ich von einem Test von außen eher ab, also z. B. mit badblocks, um frühzeitig Fehler zu finden. Wenn der Selbstest der Platte sagt, daß alles okay sei, wird die Platte bestimmt nicht dem badblocks-Programm plötzlich Fehler offenbaren (sondern die Sektoren stillschweigen ummappen o. ä.). Mit dftview kann man dem DFT-Logs allerdings nette Details entlocken, welche meines Wissens auch nicht über SMART propagiert werden: "Defect map", "Time-ordered relocations", "Scratch list" und "Problematic LBA list". Deine Skepsis gegenüber SMART ist also in der Tat angebracht, die herstellerspezifischen Tests sind detailierter, aber halt auch nur mit spezieller Software; die oben genannten Daten verrät der DFT nämlich auch nicht wirklich.
(...).
Es gilt schon prinzipiell nur diese Richtung: SMART sagt kaputt -> die Platte ist wohl kaputt
In der Praxis sagt SMART vermutlich meistens gar nichts, weil die Platten gar nicht mehr antworten :)
Der war gut! :D
Weiss nicht, vielleicht spielen da auch Gewährleistungsgründe ne Rolle. Hat eine Platte Fehlereinträge etc., könnte ich sie ja tauschen wollen. Überzeugenden Gerüchten zufolge haben Platte eh /immer/ Fehler, weil das eine Staubkorn pro Kubikmeter irgendwo dann doch ein Loch geschlagen hat, diese aber automatisch reallokiert werden, so dass man es nicht sieht.
Ohne die Schwelle zu kennen, ab wann der SMART-Wert, der angibt wieviele Sektoren umgemappt wurden, erhöht wird, ist ein Wert von 0 nicht sonderlich vertrauenserweckend. Ein Wert von größer als 0 ist IMHO aber auch ohne Kenntnis der Schwelle besorgniserregend, denn SMART schönt die Werte eher.
Früher waren Aufkleber mit der "defect block list" drauf, heute ist das in Software versteckt. Aber der gleiche Fakt. Schon alleine, dass man diese im SMART nicht sieht, zeigt ja, dass SMART "lügt".
Klar, die Folgerung "SMART sagt ok -> Platte ist ok" kann nie richtig sein; aber unabhängig davon wie ehrlich SMART ist.
So kann man nicht einschätzen, ob man orginal 5 kaputte Sektoren (gute Platte) oder 50 (schlechte Platte - Zahlen geraten) hatte. Vermutlich eher 50, weil die mit 5 vermutlich ein SCSI Interface bekommen haben, um überhaupt irgendein Argument zu haben, warum Platten mit solchen Kontrollern plötzlich deutlich teuerer sind (und noch teurer, wenn links und rechts ein Spannungspin am Stecker mit dran ist - sicherlich liegt der Preisunterschied nicht am Stecker selbst ;)).
Du bist echt ein Realist. :-D
Eine Anekdote aus den letzten Wochen: Lernpartner hat seinen PC umgebaut und eine Platte im Wechselramen mit einem 40-poligen IDE-Kabel angeschlossen. Naja, im Log fanden sich dann natürlich die typischen Platte-liegt-im-Sterben-DMA-Fehlermeldungen. Fehlerlog der Platte sah das ähnlich, aber "UDMA_CRC_Error_Count" war recht hoch,
Da gibt's also mindestens eine SMART-Implementierung, die etwas tut :)
Perfekt ausgedrückt. ;) Ganz nutzlos ist es also nicht.
(...). Da es für Kunden sicherlich besser aussieht, wenn bei SMART nix kommt, und Firmen ja es für die Kunden immer besser aussehen lassen wollen, liegt der Verdacht nahe (und zeigt meine minimale persönliche Erfahrung), dass bei SMART halt (fast) nix kommt. Ist ne Platte wirklich kaputt, ist's nämlich eh egal.
Traurig, aber wohl ziemlich wahr.
Sprich, SMART ist genauso nützlich wie jeder andere Test auch.
Oder wie Studien. Da kann man sich über den Sponsor auch aussuchen, was bei rauskommen soll :-)
Obwohl, daß was in http://www.heise.de/newsticker/meldung/66769 steht klingt für mich ziemlich nachvollziehbar: | Studien, die im Sinne des Auftraggebers bilanzieren, würden gezielt zu | Marketing-Zwecken eingesetzt. Studien mit negativer Bilanz hingegen | dienten den Entwicklern zur Produktverbesserung und blieben | unveröffentlicht. So entstehe in der Öffentlichkeit ein verzerrtes Bild | von Auftragsstudien.
Wenn der Test erfolgreich ist (d. h. es wurde ein Fehler gefunden), dann weiß man, daß das Testobjekt fehlerhaft ist, ansonsten ist man aber keinen Deut schlauer als vorher.
Ja, Du willst auf die "logische" Limitierung ("Testen kann man nur die Anwesenheit von Fehlern, nicht deren Abwesenheit"), hinaus, die natürlich vollkommen richtig und eh immer da ist - aber ich denke, SMART ist längst nicht so gut/genau/ehrlich.
IMHO: Ein schlechter Test ist besser als gar keiner, solange man um obige Limitierung weiß.
00 00 3f 00 00 00 b0 10 25.500
muss zugeben, dass mir das überhaupt nichts sagt :-)
Hmm. Bei der Augabe von meinem smartctl ist da noch eine Spalte "Command/Feature_Name".
Gut, mein tool ist sicherlich etwas ältlich ;)
BTW, der Autor von den smartmontools schreibt oder schrieb lustigerweise auch in de.comp...festplatten.
Ich hab einen Log-Eintrag von meinem Versuch den Write-Cache auszuschalten:
(auch so ein Ding, warum geht das nicht absolut immer? Vielleicht geht es ja NIE, aber manche Platten melden den Fehler bloss nicht :))
Du bist böse! ;) http://wipe.sourceforge.net/ | (...). Unfortunetly, not all drives actually disable write cache when | asked to. Those drives are broken. Write caching should always be | disabled, unless your system is battery backed and always powers down | cleanly. See this thread from the linux kernel list: | | http://www.uwsg.iu.edu/hypermail/linux/kernel/0103.0/0331.html
(...). "Set transfer mode" war vorher? Oder hat es tatsächlich etwas mit Setting cache mode zu tun? Kann ja sein, dass in irgendeinem IDE Standard sowas steht, hab da NULL Ahnung, aber klingt zumindestens nicht wirklich hilfreich.
Ich bin mir ziemlich sicher, daß das der Versuch war, den Write-Cache auszuschalten. Vor allem wegen der "Powered_Up_Time" von 6 Minuten, denn das hab ich so ziemlich als erstes probiert.
(...).
"smartctl -l selftest /dev/hda" zeigt dann das Log der Selbsttests an
Hast Du da mehr als einen Eintrag?
Ja, pro Selbsttest einen. Bei meiner kaputten IBM also 6 Stück oder so.
Ich hab auf zwei verschiedenen Platten genau einen Eintrag (wie auch immer der da reingekommen ist), obwohl schon mehrmals smartctl -t etc. gemacht.
Du verunsicherst mich immer mehr! :-P Also meine Seagate-, Samsung- und IBM-Platten haben bzw. hatten alle mehr als einen Eintrag.
Vielleicht ist der Eintrag hardcoded, damit (halb-)schlaue monitortools "ihrern" Testversuch immer "sehen" und nicht warnen, dass SMART "komisch" ist :-)
Hatte ich schon erwähnt, daß du böse bist! :)
Natürlich alle ohne Fehler. X-)
Muss dann wohl am Kabel liegen :-)
Hatte ich schon erwähnt, daß du ... Danke für diese spannende und anspruchsvolle Diskussion Jan -- Vulcan Borg: Live long and assimilate!
participants (8)
-
Christian Boltz -
David Haller -
Jan -
Jan Ritzerfeld -
Johannes Kapune -
Kay Patzwald -
Steffen Dettmer -
Thomas Hertweck