Wochen lang hatte ich unter 8.1 nach einem Update auf k_deflt-2.4.19-202.i586.rpm keine Probleme mehr und plötzlich hatte ich an 1 Tag 2x Probleme. Da ich meine Server nicht permanent beobachte, war die HD längere Zeit im vollen Dauerbetrieb, was zu defekten Sektoren und einer defekten Partition führte. Zufällig ging ich vorbei und hörte verdächtige HD-Geräusche. Nach dem nächsten reboot war ein manuelles Reparieren angesagt. Da ich eine Sicherung hatte, habe ich auf die Wiederherstellung von lost+found verzichtet und zuückgesichert. Gehört so ein Problem unter 8.2 nun der Vergagenheit an bzw. welchen Kernel enthält 8.2? Al
Hartmut Meyer schrieb:
Hallo,
Am Mittwoch, 2. April 2003 21:28 schrieb Al Bogner:
[...]
Zufällig ging ich vorbei und hörte verdächtige HD-Geräusche.
Gegen _den_ "IDE-Bug" hilft kein Kernel-Update!
Tolle Aussage ! Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ? Kernel 2.4.20 Vanilla tuts hier prächtig, ausser das beschi** Quota :-( Gruss Patrick Klaus
Hallo, Am Mittwoch, 2. April 2003 21:39 schrieb Patrick Klaus:
Hartmut Meyer schrieb:
Hallo,
Am Mittwoch, 2. April 2003 21:28 schrieb Al Bogner:
[...]
Zufällig ging ich vorbei und hörte verdächtige HD-Geräusche.
Gegen _den_ "IDE-Bug" hilft kein Kernel-Update!
Tolle Aussage !
Ich glaube du hast mich nicht richtig verstanden: wenn seine Festplatte komische Geräusche macht, dann ist sie eben kaputt (bzw. wird es bald sein). Das hat mit dem Kernel nix zu tun. Schöne Grüße aus Bremen hartmut
Patrick Klaus wrote:
Hartmut Meyer schrieb:
Am Mittwoch, 2. April 2003 21:28 schrieb Al Bogner: [...]
Zufällig ging ich vorbei und hörte verdächtige HD-Geräusche.
Gegen _den_ "IDE-Bug" hilft kein Kernel-Update!
Tolle Aussage !
Hallo aufwachen! Was Hartmut wohl sagen wollte, ist, dass bei dem IDE-Bug hier (= Hardwareschaden, siehe Festplattengeraeusche) kein Kernel-Update hilft.... Damit hat er natuerlich 100% Recht.
Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ?
Weil eben einer der SuSE-Patches den Bug getriggert hat - beim Vanilla-Kernel ist er deswegen wohl nicht aufgetreten.
Kernel 2.4.20 Vanilla tuts hier prächtig, ausser das beschi** Quota :-(
Ich bin auch sehr zufrieden mit meinem Vanilla 2.4.20-xfs. Da geht auch Quota. CU, Th. PS: Du plenkst! -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Thomas Hertweck schrieb:
Kernel 2.4.20 Vanilla tuts hier prächtig, ausser das beschi** Quota :-(
Na reiserfs, ext2 und ext3 geht nicht. Vielleicht sollte ich mal als allerletztes XFS ausprobieren Oder mir SuSE 8.2 mal anschauen, wie die das da gelöst haben, ist ja auch ein 2.4.20er Kernel denke ich Gruss Patrick Klaus
On Donnerstag, 3. April 2003 00:25 Thomas Hertweck wrote:
Hallo aufwachen! Was Hartmut wohl sagen wollte, ist, dass bei dem IDE-Bug hier (= Hardwareschaden, siehe Festplattengeraeusche) kein Kernel-Update hilft.... Damit hat er natuerlich 100% Recht.
Das ist mir auch klar und die HD hatte wirklich dann gestern den Geist aufgegeben. Aber nach einer "low lovel Formatierung" mit den Tools von Maxtor mag sie wieder. Ich frage mich daher, ob die HD-Probleme *durch* den IDE-Bug entstanden sind und ob es unter Linux auch ein Tool gegeben hätte, die HD wieder funktionsfähig zu machen. Mit e2fsck war keine Reparatur möglich, es waren 4 ext3-Partitonen vorhanden. Der HD traue ich nun nicht mehr, obwohl sie wieder zu funktionieren scheint. Für die Daten existiert eine Sicherung, also ist es nur halb so schlimm. Wie kann ich die HD nun testen, ob sie wirklich wieder zuverlässig in der nächsten Zeit funktionieren will? Beim low-level Format gab es ziemlich laute "kratzende" HD-Geräusche und die waren eher beunruhigned. Ich habe auf die HD noch ca. 1 Jahr Garantie (von 3 Jahren). Macht es Sinn große Dateien auf der HD hin- und her zo kopieren oder wie könnte man die HD anders belasten um zu sehen, ob sie nicht gleich wieder Probleme macht? Al
Al Bogner wrote:
[...] Das ist mir auch klar und die HD hatte wirklich dann gestern den Geist aufgegeben. Aber nach einer "low lovel Formatierung" mit den Tools von Maxtor mag sie wieder.
Ich frage mich daher, ob die HD-Probleme *durch* den IDE-Bug entstanden sind und ob es unter Linux auch ein Tool gegeben hätte, die HD wieder funktionsfähig zu machen. Mit e2fsck war keine Reparatur möglich, es waren 4 ext3-Partitonen vorhanden.
Tools wie e2fsck, reiserfsck etc. sind dazu gedacht, das Filesystem zu reparieren. Ist die darunter liegende Hard- ware kaputt, so koennen auch diese Programme daran nichts reparieren - das einzige, was sie tun koennen, ist dafuer zu sorgen, dass die kaputten Bereiche auf der Festplatte in Zukunft von der Verwendung ausgeschlossen werden. So etwas macht dann "badblocks" zum Beispiel. Nichts desto trotz bleibt die Hardware kaputt, auch wenn Du die Symp- tome dann nicht mehr zu sehen bekommst. Eine Low-Level-Formatierung (wusste gar nicht, dass das bei modernen Festplatten noch geht und vom User gemacht werden kann) geht das Problem auf einer tieferen Ebene an. Aber auch hier gilt: gibt es einen Hardwareschaden, so kann das nicht repariert werden. Es kann nur dafuer ge- sorgt werden, dass die kaputten Bereiche von der Verwen- dung ausgeschlossen werden. Normalerweise hat jede Fest- platte Ersatzsektoren, die kaputte andere Sektoren er- setzen, ohne dass der Anwender oder das Filesystem davon etwas mitbekommt (das laeuft auf Hardwareebene) - wenn man also als User etwas mitbekommt, dass Sektoren kaputt sind, dann ist das quasi schon das Endstadium einer Platte, und die Probleme werden sicher eher zu- als abnehmen!
Der HD traue ich nun nicht mehr, obwohl sie wieder zu funktionieren scheint. Für die Daten existiert eine Sicherung, also ist es nur halb so schlimm. Wie kann ich die HD nun testen, ob sie wirklich wieder zuverlässig in der nächsten Zeit funktionieren will? Beim low-level Format gab es ziemlich laute "kratzende" HD-Geräusche und die waren eher beunruhigned. Ich habe auf die HD noch ca. 1 Jahr Garantie (von 3 Jahren). Macht es Sinn große Dateien auf der HD hin- und her zo kopieren oder wie könnte man die HD anders belasten um zu sehen, ob sie nicht gleich wieder Probleme macht?
Das einzige, was IMHO Sinn macht, ist, die Garantie zu nutzen und die Platte umzutauschen. Wie oben schon er- waehnt: man doktort mehr oder weniger nur an den Sympto- men rum. Frueher oder spaeter werden wieder Probleme auf- tauchen. Wenn Du die Platte belasten willst, dann kopie- re von dieser Platte auf diese Platte grosse Dateien. Oder schreibe ein kleines C-Prograemmchen, was in einer grossen Datei zufaellige Positionen anfaehrt (seek) und dann dort ein paar Bytes liest und in einer andere Datei schreibt. Oder denke Dir einfach aehnliche Spielchen aus :-) Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hallo, On Sat, 05 Apr 2003, Thomas Hertweck wrote:
Al Bogner wrote:
[...] Das ist mir auch klar und die HD hatte wirklich dann gestern den Geist aufgegeben. Aber nach einer "low lovel Formatierung" mit den Tools von Maxtor mag sie wieder.
Ich frage mich daher, ob die HD-Probleme *durch* den IDE-Bug entstanden sind
Nein.
und ob es unter Linux auch ein Tool gegeben hätte, die HD wieder funktionsfähig zu machen.
badblock bzw. mkfs.ext3 -c, aber s.u.
Mit e2fsck war keine Reparatur möglich, es waren 4 ext3-Partitonen vorhanden. [..] reparieren - das einzige, was sie tun koennen, ist dafuer zu sorgen, dass die kaputten Bereiche auf der Festplatte in Zukunft von der Verwendung ausgeschlossen werden. So etwas macht dann "badblocks" zum Beispiel. Nichts desto trotz bleibt die Hardware kaputt, auch wenn Du die Symp- tome dann nicht mehr zu sehen bekommst. Eine Low-Level-Formatierung (wusste gar nicht, dass das bei modernen Festplatten noch geht und vom User gemacht werden kann)
Das ist keine "Low-Level"-Formatierung wie du sie meinst, das macht im Prinzip nur ein badblocks intern auf der HD, d.h. die schon defekten Sektoren werden versteckt. [..]
dung ausgeschlossen werden. Normalerweise hat jede Fest- platte Ersatzsektoren, die kaputte andere Sektoren er- setzen, ohne dass der Anwender oder das Filesystem davon etwas mitbekommt (das laeuft auf Hardwareebene) - wenn man also als User etwas mitbekommt, dass Sektoren kaputt sind, dann ist das quasi schon das Endstadium einer Platte, und die Probleme werden sicher eher zu- als abnehmen!
Ack.
Das einzige, was IMHO Sinn macht, ist, die Garantie zu nutzen und die Platte umzutauschen.
Jep. -dnh -- Listen, three eyes, don't you try to outweird me. I get stranger things than you free with my breakfast cereal. -- Zaphod Beeblebrox
On Samstag, 5. April 2003 13:46 David Haller wrote:
Das ist keine "Low-Level"-Formatierung wie du sie meinst, das macht im Prinzip nur ein badblocks intern auf der HD, d.h. die schon defekten Sektoren werden versteckt.
Ich habe mich auch gewundert, da es IMO nur bei SCSI-Platten möglich ist ein Lowlevel-Format zu machen, aber nicht bei IDE. Maxtor bezeichnet es aber bei seinem Programm mit "Lowlevel"
Das einzige, was IMHO Sinn macht, ist, die Garantie zu nutzen und die Platte umzutauschen.
Die Frage ist, ob Maxtor eine Platte als Garantiefall akzeptiert, die mit ihrem Programm keine Fehler anzeigt. Ich bin gerade dabei ein Standardsystem zu installieren und dann mal e2fsck -C darüber laufen zu lassen. Bin schon neugierig was da angezeigt wird. Al
Hallo, On Sat, 05 Apr 2003, Al Bogner wrote:
On Samstag, 5. April 2003 13:46 David Haller wrote:
Das ist keine "Low-Level"-Formatierung wie du sie meinst, das macht im Prinzip nur ein badblocks intern auf der HD, d.h. die schon defekten Sektoren werden versteckt.
Ich habe mich auch gewundert, da es IMO nur bei SCSI-Platten möglich ist ein Lowlevel-Format zu machen, aber nicht bei IDE.
Aehm, AFAIK geht das auch bei SCSI-HDDs nicht mehr, die sind intern inzwischen weitgehend identisch zu den IDE-HDDs (ok, die Teile drehen schneller, sind ausgesucht, haben eine andere Elektronik, teilweise auch kleinere Scheiben, ne bessere Garantie, aber ansonsten??) Das "ehemalige" low-level-Format ist rein technisch einfach nicht mehr moeglich. Das geht bei Disketten noch, wenn man z.B. mit fdformat auf z.B. 1760 KB umformatiert...
Maxtor bezeichnet es aber bei seinem Programm mit "Lowlevel"
man Marketing, is halt was anderes, zugegebenermassen "unterhalb" einer normalen Formatierung angesiedelt, und da man diesen schoenen Begriff "lowlevel formatting" noch in der Schublade hat... Wie die das (und AFAIK praktisch alle anderen Hersteller) bezeichnen, interessiert aber doch eigentlich nicht, oder?
Das einzige, was IMHO Sinn macht, ist, die Garantie zu nutzen und die Platte umzutauschen.
Die Frage ist, ob Maxtor eine Platte als Garantiefall akzeptiert, die mit ihrem Programm keine Fehler anzeigt.
Jep. Ich hoffe es fuer dich. Und lass ggfs. dein Wissen (das du dir spaetestens wohl hier im Thread angeeignet hast) "raushaengen" und lass dich nicht von denen "verscheissern". Die Hotline (oder was auch immer) wird das sehr sicher so oder so probieren ("das is normal"). Oder Maxtor ist doch besser als ich vermute ;) Teile doch bitte mir/uns das Ergebnis mit[1].
Ich bin gerade dabei ein Standardsystem zu installieren und dann mal e2fsck -C darüber laufen zu lassen. Bin schon neugierig was da angezeigt wird.
"e2fsck -C" ??? ==== man e2fsck ==== -C This option causes e2fsck to write completion information to the specified file descriptor so that the progress of the filesystem check can be monitored. ==== Was du vermutlich durcheinander bringst sind 'badblocks' und 'mke2fs -c'. Letzteres willst du ganz sicher NICHT auf deiner vorhandenen Partition laufen lassen... -dnh [1] vielleicht probiere ich dann mal nen "Lagerschaden" zu reklamieren *eg* --
BSD, Berkeley ca. 1980, LSD, Zürich, 1949, oder? LSD, Basel, 1938. 1980-1938=42 -- Irgendwie kann das kein Zufall sein :-) -- D. Proepper, R. Huemmer und T. Köhler in dasr
On Samstag, 5. April 2003 19:27 David Haller wrote:
Das einzige, was IMHO Sinn macht, ist, die Garantie zu nutzen und die Platte umzutauschen.
Ok, ich habe ja noch über 1 Jahr Garantie und ich bin mir sicher, dass die wieder mal "hängen" bleibt. Dann mache ich kein "low level" mehr.
Die Frage ist, ob Maxtor eine Platte als Garantiefall akzeptiert, die mit ihrem Programm keine Fehler anzeigt.
Jep. Ich hoffe es fuer dich. Und lass ggfs. dein Wissen (das du dir spaetestens wohl hier im Thread angeeignet hast) "raushaengen" und lass dich nicht von denen "verscheissern".
Man muß mit denen geduldig sein. Ich habe dem Support bereits 3x erklärt, dass es sich um ein Linux-only Rechner hat und ich daher mit dem per Attachment geschickten über 2MB großen Win-Programm nichts anfangen kann. Mal sehen, ob die Linux verstehen, wenn man es in Großbuchstaben schreibt. Da ich zu Ergebnissen kommen will, habe ich mir einen Windows-Rechner gesucht und dann dort diese Überprüfungsdiskette erstellt. Ich finde die sollten auch für Linux-Anwender ein Image liefern und eine Erklärung im email dazu schreiben, wie man an einer Konsole davon eine Diskette erstellt. *Das* wäre ein Service! Bevor ich die aber noch mal kontaktiere. möchte ich konkrete Aussagen treffen können.
Hotline (oder was auch immer) wird das sehr sicher so oder so probieren ("das is normal"). Oder Maxtor ist doch besser als ich vermute ;) Teile doch bitte mir/uns das Ergebnis mit[1].
Mache ich. Ich habe die Platte jetzt in einen anderen Rechner eingebaut und werde sie dort etwas intensiver benutzen. Wie kann ich eigentlich alle Dateien eines Verzeichnisses *gleichzeitig* kopieren?
Ich bin gerade dabei ein Standardsystem zu installieren und dann mal e2fsck -C darüber laufen zu lassen. Bin schon neugierig was da angezeigt wird.
"e2fsck -C" ???
==== man e2fsck ==== -C This option causes e2fsck to write completion information to the specified file descriptor so that the progress of the filesystem check can be monitored. ====
also e2fsck (ohne c!) -C test.txt /dev/hdc7 erzeugt keine Datei. Ich hätte gerne eine Datei, bei der alle ausgemappten Sektoren gelistet sind.
Was du vermutlich durcheinander bringst sind 'badblocks' und 'mke2fs -c'. Letzteres willst du ganz sicher NICHT auf deiner vorhandenen Partition laufen lassen...
Der Hinweis mke2fs stammt nicht von mir. Der Rechner enthält jetzt eine 8.1 Standard-Installation mit Test-Dateien. Ich kopiere augenblicklich ein paar GB zwischen 2 Partitionen. Hat da wer eine Idee für ein simples Shellscript, dass die HD stärker fordert? Siehe auch oben. Mit einer nachvollziehbaren Fehlermeldung mit dem Maxtor-Tool stehen meine Karten nämlich viel besser. Für mich ist es auch irgendwie ein zeitlichens Problem. Ich kann die HD nicht ewig im anderen Rechner lassen und in den ursprünglichen Rechner kommt eine neue HD rein. Al
Hallo, On Sat, 05 Apr 2003, Al Bogner wrote:
On Samstag, 5. April 2003 19:27 David Haller wrote: [..]
Die Frage ist, ob Maxtor eine Platte als Garantiefall akzeptiert, die mit ihrem Programm keine Fehler anzeigt.
Jep. Ich hoffe es fuer dich. Und lass ggfs. dein Wissen (das du dir spaetestens wohl hier im Thread angeeignet hast) "raushaengen" und lass dich nicht von denen "verscheissern".
Man muß mit denen geduldig sein. Ich habe dem Support bereits 3x erklärt, dass es sich um ein Linux-only Rechner hat und ich daher mit dem per Attachment geschickten über 2MB großen Win-Programm nichts anfangen kann.
*GRRR*
Mal sehen, ob die Linux verstehen, wenn man es in Großbuchstaben schreibt.
<mode type="Glaskugel"> Nein. </mode>
Hotline (oder was auch immer) wird das sehr sicher so oder so probieren ("das is normal"). Oder Maxtor ist doch besser als ich vermute ;) Teile doch bitte mir/uns das Ergebnis mit[1].
Mache ich. Ich habe die Platte jetzt in einen anderen Rechner eingebaut und werde sie dort etwas intensiver benutzen. Wie kann ich eigentlich alle Dateien eines Verzeichnisses *gleichzeitig* kopieren?
Hm. Da koennte man was zusammenbasteln, spontan (nein, das wird sehr wahrscheinlich nicht funktionieren): find irgendwo -type f | \ while read f; do { cp -a "$f" woanders/ & }; done Die Dateien am Zielort sind aber sicher nicht "korrekt" und das macht wohl sowieso nicht das, was du eigentlich damit bezwecken willst, s.u.
Ich bin gerade dabei ein Standardsystem zu installieren und dann mal e2fsck -C darüber laufen zu lassen. Bin schon neugierig was da angezeigt wird.
"e2fsck -C" ??? [..] also e2fsck (ohne c!) -C test.txt /dev/hdc7 erzeugt keine Datei.
RTFM. Das erzeugt ein Fortschrittsanzeige. Und das Argument fuer die Option -C ist keine Datei, sondern ein Dateideskriptor! Mach mal auf einer ro oder unmounteten Partition (ist ungefaehrlich): e2fsck -f -C 1 /dev/hdXY Was die '1' zu bedeuten hat? Nunja, mach ein ls -l /dev/fd/1 ;) Interessant finde ich allerdings das Verhalten, wenn FD 0 angegeben wird *g*
Ich hätte gerne eine Datei, bei der alle ausgemappten Sektoren gelistet sind.
Flasches Tool. Du willst 'man badblocks' lesen ;) Achso, und die (defekten) Sektoren, die die HD erstens sowieso intern schon hat verschwinden lassen, und nun, nach dem "Lowlevel-Format" auch alle spaeteren, an die wirst du nicht mehr herankommen, allerdings muesste deine HDD nun ein klein wenig "geschrumpft" sein...
Was du vermutlich durcheinander bringst sind 'badblocks' und 'mke2fs -c'. Letzteres willst du ganz sicher NICHT auf deiner vorhandenen Partition laufen lassen...
Der Hinweis mke2fs stammt nicht von mir.
Stimmt. Aber eben weil du e2fsck missverstanden hast, ein mke2fs -c macht beim Erstellen des FS einen Check auf defekte Sektoren und mappt die defekten Sektoren direkt in eine Datei .badblocks... [..]
Hat da wer eine Idee für ein simples Shellscript, dass die HD stärker fordert?
Hm. Nach dem "Lowlevel-Format" musst du leider "neue" Defekte provozieren (wenn du defekte Sektoren haben willst), d.h. du beschleunigst den Gang der HD in den Orkus... Um neue Defekte zu provozieren, d.h. um die HD zu strapazieren, wuerde ich wohl tar verwenden, das z.B. einen "passende" Datenmenge staendig hin- und herkopiert... ==== UNGETESTET! ==== trap "exit 0" 2 while true; do cd /mnt/blubb; tar cp . | (cd /mnt/bla; tar xp) cd /mnt/bla; tar cp . | (cd /mnt/blubb; tar xp) done ==== Das schaufelt bis zum "SIGINT" (d.h. Strg-C)... /mnt/blubb und /mnt/bla sollten dabei 2 Partitionen auf der "verdaechtigen" HD sein, ansonsten bitte durch passende Verzeichnisse ersetzen ;) -dnh -- Black holes are where God divided by zero! -- stolen from Carsten Groh
On Samstag, 5. April 2003 22:17 David Haller wrote:
Achso, und die (defekten) Sektoren, die die HD erstens sowieso intern schon hat verschwinden lassen, und nun, nach dem "Lowlevel-Format" auch alle spaeteren, an die wirst du nicht mehr herankommen, allerdings muesste deine HDD nun ein klein wenig "geschrumpft" sein...
Ich hab mir das zwar persönlich noch nicht näher angesehen, aber unter Win soll scandisk optisch die defekten Blöcke anzeigen. Gibt es so was ähnliches nicht unter Linux? Inwieweit die HD geschrumpft ist, kann *ich* nicht sagen. So sieht die augenblickliche Testvariante aus: Maxtor 96147H6 (60 GB) Filesystem Type 1K-blocks Used Available Use% Mounted on /dev/hdc5 ext2 2064144 1471176 488088 76% / /dev/hdc1 ext2 63893 4457 56137 8% /boot /dev/hdc6 ext2 27660688 26019028 236560 100% /test1 /dev/hdc7 ext2 27646072 26019028 222676 100% /test2 shmfs shm 128040 0 128040 0% /dev/shm Disk /dev/hdc: 16 heads, 63 sectors, 116301 cylinders Units = cylinders of 1008 * 512 bytes Device Boot Start End Blocks Id System /dev/hdc1 1 131 65992+ 83 Linux /dev/hdc2 132 652 262584 82 Linux swap /dev/hdc3 653 116301 58287096 f Win95 Ext'd (LBA) /dev/hdc5 653 4814 2097616+ 83 Linux /dev/hdc6 4815 60572 28102000+ 83 Linux /dev/hdc7 60573 116301 28087384+ 83 Linux Das habe ich in messages gefunden: Apr 3 20:19:07 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 Apr 3 20:19:07 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128 Apr 3 20:19:10 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 3 20:19:10 server kernel: hdc: read_intr: error=0x01 { AddrMarkNotFound }, LBAsect=87911808, sector=4128 Apr 3 20:19:14 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 3 20:19:14 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 Apr 3 20:19:14 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128 Al
Hallo, nach Zeitmangel und Festplattenschaden (vermutlich, unten dazu mehr) bin ich jetzt hoffentlich länger wieder da. Und da wir grad bei den Festplatten sind... * Al Bogner textete am 06.04.03:
On Samstag, 5. April 2003 22:17 David Haller wrote:
Das habe ich in messages gefunden:
Apr 3 20:19:07 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 Apr 3 20:19:07 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128 Apr 3 20:19:10 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 3 20:19:10 server kernel: hdc: read_intr: error=0x01 { AddrMarkNotFound }, LBAsect=87911808, sector=4128 Apr 3 20:19:14 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 3 20:19:14 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 Apr 3 20:19:14 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128
Bei dir sind es vielleicht nicht direkt defekte Sektoren, aber das Ergebnis dürfte das Gleiche sein: Keine wichtigen Daten auf diese Platte! Bei mir sieht das so aus [1]: (Sorry für die überlangen Zeilen) Apr 5 03:24:39 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:39 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:40 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:40 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:40 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:40 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:40 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:40 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:40 grossing kernel: hda: DMA disabled Apr 5 03:24:40 grossing kernel: hdb: DMA disabled Apr 5 03:24:40 grossing kernel: ide0: reset: success Apr 5 03:24:41 grossing kernel: hda: multwrite_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:41 grossing kernel: hda: multwrite_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:41 grossing kernel: hda: multwrite_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:41 grossing kernel: hda: multwrite_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:42 grossing kernel: hda: multwrite_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:42 grossing kernel: hda: multwrite_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:42 grossing kernel: hda: multwrite_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:42 grossing kernel: hda: multwrite_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787974 Apr 5 03:24:42 grossing kernel: ide0: reset: success Apr 5 03:24:43 grossing kernel: hda: write_intr error1: nr_sectors=96, stat=0x51 Apr 5 03:24:43 grossing kernel: hda: write_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:24:43 grossing kernel: hda: write_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=788132 Apr 5 03:34:24 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:24 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787878 Apr 5 03:34:24 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:24 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787878 Apr 5 03:34:24 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:24 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787878 Apr 5 03:34:25 grossing kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:25 grossing kernel: hda: dma_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=787878 Apr 5 03:34:25 grossing kernel: hda: DMA disabled Apr 5 03:34:25 grossing kernel: ide0: reset: success Apr 5 03:34:25 grossing kernel: hda: write_intr error1: nr_sectors=1, stat=0x51 Apr 5 03:34:25 grossing kernel: hda: write_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:25 grossing kernel: hda: write_intr: error=0x10 { SectorIdNotFound }, CHS=781/14/3, sector=788131 Apr 5 03:34:27 grossing kernel: hda: write_intr error1: nr_sectors=41, stat=0x51 Apr 5 03:34:27 grossing kernel: hda: write_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:27 grossing kernel: hda: write_intr: error=0x10 { SectorIdNotFound }, CHS=785/5/53, sector=791647 Apr 5 03:34:55 grossing kernel: hda: write_intr error1: nr_sectors=91, stat=0x51 Apr 5 03:34:55 grossing kernel: hda: write_intr: status=0x51 { DriveReady SeekComplete Error } Apr 5 03:34:55 grossing kernel: hda: write_intr: error=0x10 { SectorIdNotFound }, CHS=866/15/21, sector=873893 Apr 5 03:38:51 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:51 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=742/6/56, sector=748306 Apr 5 03:38:52 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:52 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=742/10/17, sector=748519 Apr 5 03:38:54 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:54 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=743/2/58, sector=749064 Apr 5 03:38:55 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:55 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=743/2/58, sector=749064 Apr 5 03:38:56 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:56 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=743/2/58, sector=749064 Apr 5 03:38:58 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:38:58 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=743/2/58, sector=749064 Apr 5 03:38:58 grossing kernel: ide0: reset: success Apr 5 03:39:02 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:02 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/21, sector=750791 Apr 5 03:39:03 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:03 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/21, sector=750791 Apr 5 03:39:03 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:03 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/21, sector=750791 Apr 5 03:39:04 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:04 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/21, sector=750791 Apr 5 03:39:04 grossing kernel: ide0: reset: success Apr 5 03:39:04 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:04 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/25, sector=750795 Apr 5 03:39:05 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:05 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/27, sector=750797 Apr 5 03:39:06 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:06 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/27, sector=750797 Apr 5 03:39:06 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:06 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/14/27, sector=750797 Apr 5 03:39:08 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:08 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/15/8, sector=750841 Apr 5 03:39:08 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:08 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=744/15/8, sector=750841 Apr 5 03:39:16 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:16 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=749/2/16, sector=755070 Apr 5 03:39:24 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:24 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/2/29, sector=758107 Apr 5 03:39:26 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:26 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:28 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:28 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:29 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:29 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:30 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:30 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:30 grossing kernel: ide0: reset: success Apr 5 03:39:31 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:31 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:32 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:32 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:34 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:34 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:35 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:35 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:35 grossing kernel: ide0: reset: success Apr 5 03:39:36 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Apr 5 03:39:36 grossing kernel: hda: read_intr: error=0x10 { SectorIdNotFound }, CHS=752/7/47, sector=758440 Apr 5 03:39:36 grossing kernel: end_request: I/O error, dev 03:01 (hda), sector 758440 Apr 5 03:39:38 grossing kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Die restlichen ca. 5700 Zeilen erspare ich euch jetzt... Sowas taucht ab und zu noch auf... Apr 5 04:22:45 grossing kernel: hda: write_intr error1: nr_sectors=129, stat=0x51 Es handelt sich hier um eine leicht angestaubte Platte... Conner Peripherals 540MB - CFS540A Eigentlich brauche ich von der Platte nur den MBR, aber selbst da sieht es schlecht aus. Dazu steht mehr in der anderen mail. [1] Das ist das Ergebnis von badblocks in der /v/l/m. cu flo -- Du kannst hier nicht erwarten, das man etwas von dir erwartet, wenn man nichts von dir erwarten kann. [WoKo in dag°]
On Samstag, 5. April 2003 14:22 Florian Gross wrote:
Bei dir sind es vielleicht nicht direkt defekte Sektoren, aber das Ergebnis dürfte das Gleiche sein: Keine wichtigen Daten auf diese Platte!
Ich gebe dir recht, aber ich frage mich, welche Daten sind unwichtig. Ich überlege mir schon mit dieser HD VIdeos zu bearbeiten. Am risikolosesten dürfte es sein, wenn man nur damit rendered. Aber dann nutze ich die 60GB nie aus. Ich mache jetzt einen neuen Thread auf, da wir uns vom Originalthema völlig wegentfernt haben: Tools f. schadhafte HD - DFTView (was: Re: 8.2: IDE-Bug endgültig erledigt?) Al
Hallo, On Sun, 06 Apr 2003, Al Bogner wrote:
On Samstag, 5. April 2003 22:17 David Haller wrote:
Achso, und die (defekten) Sektoren, die die HD erstens sowieso intern schon hat verschwinden lassen, und nun, nach dem "Lowlevel-Format" auch alle spaeteren, an die wirst du nicht mehr herankommen, allerdings muesste deine HDD nun ein klein wenig "geschrumpft" sein...
Ich hab mir das zwar persönlich noch nicht näher angesehen, aber unter Win soll scandisk optisch die defekten Blöcke anzeigen.
Nun nicht mehr, das "Lowlevel-Format" hat die nun versteckt...
Gibt es so was ähnliches nicht unter Linux?
Nein, sowas tauch in der messages auf, wenn versucht wird darauf zuzugreifen, ansonsten, auf Anforderung finden "badblocks" eben solche "bad blocks" ;)
Inwieweit die HD geschrumpft ist, kann *ich* nicht sagen. [snip partitionstabelle]
Ja, das duerfte da auch nicht auftauchen... Ich weiss auch nicht, wie sowas laeuft, ausser das der Partition dann ein paar Sektoren fehlen... Unter Win werden die eben bei scandisk angezeigt, unter Linux braucht's AFAIK badblocks, dass die defekten Sektoren (bzw. alle Bloecke, in denen Defekte auftreten) mit der Datei .badblocks belegt... Hm. Ich hab hier grad auch ne IBM DTLA die froehlich Sektoren verliert (v.a. am Ende), evtl. teste ich da mal ein paar Details. Im Moment sind die Partitionen aber belegt...
Das habe ich in messages gefunden:
Apr 3 20:19:07 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 ^^^^^^^^ hier kann auf diesen Sektor nicht zugegriffen werden (da defekt). Ein Zugriffsversuch macht sich bei meiner o.g. DTLA z.B. durch ein *schniek schniek schniek klack* bemerkbar, bei dir duerften die Symptome aehnlich, wenn auch vom Geraeusch her etwas anders sein...
Apr 3 20:19:07 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128 Apr 3 20:19:10 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Und das sind dann nur noch die passenden Folgefehler...
Apr 3 20:19:10 server kernel: hdc: read_intr: error=0x01 { AddrMarkNotFound }, LBAsect=87911808, sector=4128
Oh, nochmal der gleiche Sektor, das waere bei mir dann das begleitet vom zweiten "schniek" aus o.g. Serie ;)
Apr 3 20:19:14 server kernel: hdc: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
s.o.
Apr 3 20:19:14 server kernel: hdc: read_intr: error=0x40 { UncorrectableError }, LBAsect=87911808, sector=4128 Apr 3 20:19:14 server kernel: end_request: I/O error, dev 16:04 (hdc), sector 4128
Oh, noch ein Versuch! Fehlt noch das "*klack*", aber das macht ja die HDD selbst... *lol* -dnh PS: Auf der HD ist _nix_ wichtiges mehr, nur noch so Zeug wie die locatedb, die DB von Compupic, wenn ich squid verwenden wuerde wohl dessen cache, ebenso wuerde ich noch nen htdig-index der HD "anvertrauen"... *lol* Kurz: Zeuch, das ich mit geringem Aufwand wiederherstellen koennte... PPS: All Hardware sucks! --
Du telefonierst mit dir selber? [R. Angenendt zu L. Donnerhacke] Also Ich mache das haeufig. Schliesslich unterhalte ich mich hier im Dienst gerne mit Leuten die Ahnung von Computer haben. Manchmal waehle ich dabei auch IP Adressen: "1-9-2-.". Was ich da tat fiehl mir erst auf, als ich den Punkt am Telefon nicht gefunden habe. -- Jens 'ich hasse Montage' Link in dasr
On Sonntag, 6. April 2003 00:56 David Haller wrote:
Hm. Ich hab hier grad auch ne IBM DTLA die froehlich Sektoren verliert (v.a. am Ende), evtl. teste ich da mal ein paar Details. Im Moment sind die Partitionen aber belegt...
Ich weise noch einmal auf den Thread "Tools f. schadhafte HD - DFTView" hin. Bitte dort weiter diskutieren. Es wäre interessant was DFT/View bei dir so anzeigt. Im Gegensatz zu mir, hast du ja eine IBM-HD. Aber wie man dort sieht, lässt sich das Tool auch für Fremdfabrikate einsetzen. Al
Hi, kleine Warnung: DFT scheint nicht sicher!
Am Sonntag, 6. April 2003 20:32 schrieb Al Bogner: On Sonntag, 6. April 2003 00:56 David Haller wrote:
Hm. Ich hab hier grad auch ne IBM DTLA die froehlich Sektoren verliert (v.a. am Ende), evtl. teste ich da mal ein paar Details. Im Moment sind die Partitionen aber belegt...
Ich weise noch einmal auf den Thread "Tools f. schadhafte HD - DFTView" hin. Bitte dort weiter diskutieren. Es wäre interessant was DFT/View bei dir so anzeigt. Im Gegensatz zu mir, hast du ja eine IBM-HD. Aber wie man dort sieht, lässt sich das Tool auch für Fremdfabrikate einsetzen.
Al Ich habe auf einer DTLA DFT von IBM testhalber angewendet, Ergebnis: alles OK, keine Fehler. 2 Monate später war sie tot. Ob es damit zusammenhängt, weiß ich nicht, war aber wegen massivem Datenverlust ärgerlich! Gruß Peter
Peter Baumgartner wrote:
Ich habe auf einer DTLA DFT von IBM testhalber angewendet, Ergebnis: alles OK, keine Fehler. 2 Monate später war sie tot. Ob es damit zusammenhängt, weiß ich nicht, war aber wegen massivem Datenverlust ärgerlich!
Die DTLA Serie ist bekannt dafuer, einfach nur Schrott zu sein (sorry, anders kann man das nicht ausdruecken). Ich habe hier auch noch eine DTLA 60 GB, die munter Sektoren verliert und Davids beruehmte "schniek, schnieck, schniek, klack"(tm) Geraeusche macht ;-) Werde die demnaechst mal an IBM/Hitachi schicken samt DFT Ergebnis und hof- fentlich eine neue bekommen (ist noch Garantie drauf)... Backup ist natuerlich vorhanden. Gruesse, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Geraeusche macht ;-) Werde die demnaechst mal an IBM/Hitachi schicken samt DFT Ergebnis und hof- fentlich eine neue bekommen (ist noch Garantie drauf)... Backup ist natuerlich vorhanden.
Was meinst du mit DFT Ergebnis? Kann man das Logfile, das da auf die Floppy geschrieben wird, irgendwie lesbar machen? Ich habe hier auch so eine IBM-DTLA-307075 und die verliehrt auch im Monatsrythmus Sektoren, nur mein heldenhafter Händler ist der Meinung, so lange sie nicht total kaputt ist, nimmt er sie nicht zurück... :( Phil
Bitte lasse beim Zitieren die Einleitungen stehen, sonst weiss niemand mehr, wer was gesagt hat! Phil Schrettenbrunner wrote:
Geraeusche macht ;-) Werde die demnaechst mal an IBM/Hitachi schicken samt DFT Ergebnis und hof- fentlich eine neue bekommen (ist noch Garantie drauf)... Backup ist natuerlich vorhanden.
Was meinst du mit DFT Ergebnis? Kann man das Logfile, das da auf die Floppy geschrieben wird, irgendwie lesbar machen?
Das sollte besagtes Programm DFTview (siehe den Anfang des Threads) eigentlich machen. Ausserdem habe ich einen Error-Code des DFT-Laufes und kann bei Bedarf auch ne Diskette mit dem Log zurueck schicken... Bisher hat IBM da nie Probleme ge- macht mit dem Umtausch, wenngleich es ne ganze Weile geht, bis man die neue Platte hat. Wenn Dein Haendler das nicht machen will, dann wende Dich doch mal direkt an IBM/Hitachi, siehe dazu http://www.hgst.com/hdd/support/pre_rma.htm... Gruesse, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hallo, On Wed, 02 Apr 2003, Patrick Klaus wrote:
Hartmut Meyer schrieb:
Am Mittwoch, 2. April 2003 21:28 schrieb Al Bogner:
Zufällig ging ich vorbei und hörte verdächtige HD-Geräusche.
Gegen _den_ "IDE-Bug" hilft kein Kernel-Update!
Tolle Aussage !
Aber richtig. Wie soll der Kernel bitte schoen automagisch von einer defekten HDD lesen koennen??? Wenn du ein paar Seiten aus einem Buch rausreisst und verbrennst, kannst du dann die Seiten noch lesen? Ist das dann ein Bug in deiner Lese-"Software"?
Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ?
War ein "defekter" patch. -dnh -- 148: Flame Flames sind der dumpfe Knall, wenn die Schädeldecke auf die Mauer aufschlägt. (Frank Hufschmied)
On Thu, Apr 03, David Haller wrote:
Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ?
War ein "defekter" patch.
Wenn es der ist, den ich kenne, dann war er auch seit längerem im Vanilla Kernel. -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
Hallo, Am Donnerstag, 3. April 2003 06:56 schrieb Thorsten Kukuk:
On Thu, Apr 03, David Haller wrote:
Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ?
War ein "defekter" patch.
Wenn es der ist, den ich kenne, dann war er auch seit längerem im Vanilla Kernel.
Deswegen "freue" ich mich ja immer so, wenn von _dem_ IDE-Bug gesprochen wird :-( Es suggeriert immer man würde über ein bekanntes und wohldefiniertes Problem sprechen. Schöne Grüße aus Bremen hartmut
Hallo, On Thu, 03 Apr 2003, Hartmut Meyer wrote:
Hallo,
Am Donnerstag, 3. April 2003 06:56 schrieb Thorsten Kukuk:
On Thu, Apr 03, David Haller wrote:
Warum hat man den IDE-Bug nur unter nem SuSE 2.4.18 und 2.4.19 Kernel ?
War ein "defekter" patch.
Wenn es der ist, den ich kenne, dann war er auch seit längerem im Vanilla Kernel.
Ok, das war vereinfacht: zusammen mit den anderen Patches die ihr eingebaut habt, kam es zu Konflikten, die sich dann in Problemen mit IDE aeusserten. Und das ganze hatte halt ruck-zuck den Namen "IDE-Bug (der 8.0/8.1)" weg... Denn in Vanilla-Kernels trat das Problem eben nicht auf.
Deswegen "freue" ich mich ja immer so, wenn von _dem_ IDE-Bug gesprochen wird :-(
Ack. Geht mir ja auch so, es ging hier ja aber schon explizit um den, der in den SuSE-Kernels der 8.0 und 8.1 drin ist... -dnh -- 93: Emacs Warum werden die Funktionen nicht mit Passwörtern versehen? (Frank Klemm)
Hier moechte ich mal was grundsaetzliches festhalten. Die Frage ist nicht *ob* eine Festplatte kaputt geht, sondern *wann* sie kaputt geht. Das trifft nicht nur fur IDE-Geraete zu. Die Schnittstelle ueber die die Festplatte im System eingebunden ist, hat ja mit dem grundaetzlichen Aufbau der Festplatte (der ist bekanntlich ueberall gleich) nix zu tun. Und genau aus diesem Grund [wann die Festplatte kaputt geht] soll man (frau aber auch) ja auch Backups fertigen. Aprospos Backup..... Weiß von Euch evtl. jemand *wo* ich mich bezueglich des Einrichtens/Ansprechen eines SCSI-Streamers schlau machen kann? Im Benutzerhandbuch und im Admin-Handbuch las ich, dass nahezu alle SCSI-Streamer unterstuetzt werden. Aber *wie* ich den Streamer ansprechen kann, habe ich nicht gefunden. Bei google fand ich auch keine Informationen bezueglich des Einrichtens eines SCSI-Streamers. Einen Streamer kann ich nicht mounten und das Geraet heisst wohl /dev/st0 (soviel weiss ich bereits), aber wie ich an einen Treiber komme/wie ein Treiber eingerichtet wird weiss ich nicht. Auf der Homepage von HP habe ich keinen Treiber gefunden. Gibt es evtl. eine Backupsoftware die das fuer mich das erledigt (das Programm taper habe ich gefunden, aber da ich noch keinen Treiben fuer den Streamer habe, konnte ich noch keine weiteren Tests mit taper durchfuehren) ich bin von meiner bisherigen Backupsoftware ziemlich verwoehnt. [Start Exkurs zur Verstaendniss] Ich bin neu bei Linux (vorher hatte ich AmigaOS 3.9) die Backupsoftware hatte fuer mich auf das Streamerband geschrieben, so dass ich mir nie gedanken darueber machen musste, wie der Straemer angesprochen wird. Unter Linux moechte ich des Streamerband gern weiterhin als Backupmedium nutzen (DDS1-Streamer HP35480A, Rev. 1137, SCSI-2-Geraet) [Stop Exkurs zum Verstaendniss] Waere nett, wenn jemand 'nen Tipp haette. Vielen Dank im Voraus. Liebe Gruesse aus Thueringen! Carsten
Hallo Carsten, Carsten Grebehem wrote on Freitag, 4. April 2003 21:28 about Re: 8.2: IDE-Bug endgültig erledigt?:
Bei google fand ich auch keine Informationen bezueglich des Einrichtens eines SCSI-Streamers. Einen Streamer kann ich nicht mounten und das Geraet heisst wohl /dev/st0 (soviel weiss ich bereits), aber wie ich an einen Treiber komme/wie ein Treiber eingerichtet wird weiss ich nicht. Auf der Homepage von HP habe ich keinen Treiber gefunden.
Treiber? Wofür? Normalerweise wird per /dev/st0 direkt auf das Device geschrieben, ohne dass Du dafür einen speziellen Treiber brauchst, z. B. mit tar.
(DDS1-Streamer HP35480A, Rev. 1137, SCSI-2-Geraet)
Der läuft direkt unter Linux: tar -xvvf /dev/st0 / sichert die das Rootverzeichnis auf Band, dürfte allerdings ein DDS1-Band größenmässig überfordern. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo, Marcus Roeckrath wrote on Freitag, 4. April 2003 21:51 about Re: 8.2: IDE-Bug endgültig erledigt?:
tar -xvvf /dev/st0 /
muss natürlich tar -cvvf /dev/st0 / heissen. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath@gmx.de WWW : http://home.foni.net/~marcusroeckrath/
Hallo Marcus, Am Freitag, 4. April 2003 21:51 schrieb Marcus Roeckrath:
Treiber? Wofür?
Normalerweise wird per /dev/st0 direkt auf das Device geschrieben, ohne dass Du dafür einen speziellen Treiber brauchst, z. B. mit tar.
(DDS1-Streamer HP35480A, Rev. 1137, SCSI-2-Geraet)
Der läuft direkt unter Linux:
tar -xvvf /dev/st0 /
Vielen Dank fuer Deinen Tip. Als ich (der user) versuchte auf /dev/st0 zuzugreifen hatte ich dafuer keine Berechtigung. Nach Deiner Mail habe ich als root probiert den Streamer anzusprechen und das hat prima funktioniert. Eben habe ich mir (dem user) noch den Zugriff auf /dev/st0 einraeumt und jetzt kann ich (als user) die Datensicherung selbst vornehmen. Nochmals Danke! Liebe Gruesse aus Thueringen! Carsten
participants (11)
-
Al Bogner -
Carsten Grebehem -
David Haller -
Florian Gross -
Hartmut Meyer -
Marcus Roeckrath -
Patrick Klaus -
Peter Baumgartner -
Phil Schrettenbrunner -
Thomas Hertweck -
Thorsten Kukuk