Hallo Liebe Liste, zum generellen Verständnis erstmal: das ist hier ja eine Liste für OpenSuse Benutzer. Das Problem das ich jetzt habe ist aber leider auf einer Debian Sarge, darf ich Probleme dazu trotzdem hier stellen? Ich denke mal dass das Problem eher nicht Distributionsabhängig ist. Naja ich stelle einfach mal die Frage, vielleicht findet sich die Antwort ja ganz einfach, wenn nicht dann reicht eine kurze Info, das so ein verhalten unerwünscht ist. Also Ich habe zwei SCSI Seagate Barracudas 34 GiB. sda (~37°C) ist besser gekühlt als sdb (~45°C). Beide hängen am gleichen Controller und am gleichen Kabel. Ich habe ein Software Raid eingerichtet auf folgendem Weg: 1. cfdisk /dev/sd(a/b) -> jeweils den gesamten Platz in eine Partition gepackt. 2. reboot weil mdadm meckerte das sdb1, wo ich test weise ein raid eingerichtet hatte das 300 MiB groß war, nur 300 MiB groß ist. Das Problem ließ sich nicht mal damit beheben das ich die Platte herunterfuhr, ich mußte die ganze Kiste neustarten weil anscheinend der Kernel noch irgendwie die alten Partitionsdaten der Platte hatte (das hab ich mir so zusammengereimt aus einem Post im Internet). 3. mdadm --create --verbose /dev/md0 --level=raid1 -n2 /dev/sda1 /dev/sdb1 4. mit watch cat /proc/mdstat zuschauen wie die beiden Platten syncen. 5. zum Test einfach mal neustarten und schauen ob alles läuft. cat /proc/mdstat spuckt aus: Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 scsi/host0/bus0/target1/lun0/part1[1] 35840896 blocks [2/1] [_U] unused devices: <none> Dann hab ich noch mdadm --detail /dev/md0 gefragt. Heraus kam: /dev/md0: Version : 00.90.00 Creation Time : Tue Nov 28 05:33:29 2006 Raid Level : raid1 Array Size : 35840896 (34.18 GiB 36.70 GB) Device Size : 35840896 (34.18 GiB 36.70 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Nov 28 06:59:27 2006 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : aae453e9:c76daf64:e9e44552:a55cde6f Events : 0.7 Number Major Minor RaidDevice State 0 0 0 0 faulty removed 1 8 17 1 active sync /dev/sdb1 Dieses Verhalten, das sda aus dem Raid fliegt, kann ich immer durch reboot reproduzieren. Dann kann ich mit mdadm /dev/md0 -a /dev/sda den rebuild prozess lostreten, mdadm --detail /dev/md0 meint dazu: /dev/md0: Version : 00.90.00 Creation Time : Tue Nov 28 05:33:29 2006 Raid Level : raid1 Array Size : 35840896 (34.18 GiB 36.70 GB) Device Size : 35840896 (34.18 GiB 36.70 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Nov 28 21:52:15 2006 State : active, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 Rebuild Status : 4% complete UUID : aae453e9:c76daf64:e9e44552:a55cde6f Events : 0.8 Number Major Minor RaidDevice State 0 0 0 0 faulty removed 1 8 17 1 active sync /dev/sdb1 2 8 0 2 spare rebuilding /dev/sda Allerdings wird das ganze wieder kaputtgehen wenn ich den Rechner neustarte. Ich meine im Grunde ist das kein Riesenproblem, denn der Server soll eigentlich nie neugestartet werden, aber ich vertraue einfach meinem Raid nicht, weil es nicht läuft wie es sollte. Hat jemand schon mal so ein komisches Verhalten gehabt? Oder mache ich schlicht etwas falsch? Falls es jemand wundert (mich hat es jedenfalls gewundert): Ein mdadm /dev/md0 -a /dev/sda1 gibt mdadm: hot add failed for /dev/sda1: Invalid argument nur mdadm /dev/md0 -a /dev/sda funktioniert. Das sda hinüber ist bezweifle ich eigentlich, da der Server seit drei Monaten friedlich mit sda gearbeitet hat, sdb und sda zum gleichen Zeitpunkt gekauft wurden, daher wahrscheinlich aus der gleichen Produktionsmarge stammen und auch sonst ich einfach hoffe nur zu dumm zu sein um ein Raid aufzustellen. Vielleicht noch hilfreiche Info: sda und sdb sind reine Datenplatten. gebootet wird von einer stinknormalen Western Digital 40GB Platte. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hermann wacker wrote:
Hallo Liebe Liste,
zum generellen Verständnis erstmal: das ist hier ja eine Liste für OpenSuse Benutzer. Das Problem das ich jetzt habe ist aber leider auf einer Debian Sarge, darf ich Probleme dazu trotzdem hier stellen? Ich denke mal dass das Problem eher nicht Distributionsabhängig ist. Naja ich stelle einfach mal die Frage, vielleicht findet sich die Antwort ja ganz einfach, wenn nicht dann reicht eine kurze Info, das so ein verhalten unerwünscht ist.
Also Ich habe zwei SCSI Seagate Barracudas 34 GiB. sda (~37°C) ist besser gekühlt als sdb (~45°C). Beide hängen am gleichen Controller und am gleichen Kabel.
Welcher Controller?
Dieses Verhalten, das sda aus dem Raid fliegt, kann ich immer durch reboot reproduzieren.
Das ist doch etwas wert. Finde doch mal raus, ob der Schreibcache der Platten aktiv ist. Wenn ja, dann deaktiviere ihn und teste aus, ob es imme r noch beim reboot zu Problemen kommt. Ist das Problem dadurch gelöst, musst du zusehen, dass der Controller den Cache sauber auf die Platten leert vor dem Reboot. Ich sehe da eigentlich nur den Treiber und das SCSI-Bios als Möglichkeiten.
Vielleicht noch hilfreiche Info: sda und sdb sind reine Datenplatten. gebootet wird von einer stinknormalen Western Digital 40GB Platte.
Notfalls könntest du ein kleinen Shutdown-Script verwenden, dass dem Controller den Befehl zum Flushen des Caches gibt. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Also Ich habe zwei SCSI Seagate Barracudas 34 GiB. sda (~37°C) ist besser gekühlt als sdb (~45°C). Beide hängen am gleichen Controller und am gleichen Kabel.
Welcher Controller?
Aus der kern.log: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Nov 27 21:50:48 localhost kernel: <Adaptec 29160 Ultra160 SCSI adapter> Nov 27 21:50:48 localhost kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Nov 27 21:50:48 localhost kernel: Nov 27 21:50:48 localhost kernel: (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Nov 27 21:50:48 localhost kernel: (scsi0:A:1): 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Nov 27 21:50:48 localhost kernel: (scsi0:A:5): 40.000MB/s transfers (20.000MHz, offset 32, 16bit) Nov 27 21:50:48 localhost kernel: Vendor: SEAGATE Model: ST336607LW Rev: 0007 Nov 27 21:50:48 localhost kernel: Type: Direct-Access ANSI SCSI revision: 03 Nov 27 21:50:48 localhost kernel: Vendor: SEAGATE Model: ST336607LW Rev: 0007 Nov 27 21:50:48 localhost kernel: Type: Direct-Access ANSI SCSI revision: 03 Nov 27 21:50:48 localhost kernel: Vendor: HP Model: C5683A Rev: C111 Nov 27 21:50:48 localhost kernel: Type: Sequential-Access ANSI SCSI revision: 02
Dieses Verhalten, das sda aus dem Raid fliegt, kann ich immer durch reboot reproduzieren.
Das ist doch etwas wert. Finde doch mal raus, ob der Schreibcache der Platten aktiv ist. Wenn ja, dann deaktiviere ihn und teste aus, ob es imme r noch beim reboot zu Problemen kommt.
So, nach 30 minuten googlen habe ich leider nicht herausbekommen wie ich denn so etwas anstellen könnte, ich weiß jetzt nur das Linus Torvalds mal 2001 in einer Diskussion meinte das ide platten blöd sind, weil sie ATA FLUSH teilweise nicht kennen ;) Ne im ernst. Ich hab es mit sdparm versucht, aber ich blicke da schlicht nicht durch, ich weiß nicht mal mit welchem tool man überhaupt sehen kann was, wie und so welche Caches benutzt werden, hast du da einen Tip für mich?
Ist das Problem dadurch gelöst, musst du zusehen, dass der Controller den Cache sauber auf die Platten leert vor dem Reboot. Ich sehe da eigentlich nur den Treiber und das SCSI-Bios als Möglichkeiten.
Zum Treiber, ähem, muß ich gestehen das mein System den Controller auf magische Weise einfach so benutzt hat. Ich hab keinen Schimmer wie der Treiber heißt und wo ich da irgendwas nachschauen oder beeinflussen könnte. :-s Wegen SCSI-Bios: meinst du da das Bios vom Controller? Das einzige das ich in diese Richtung kenne ist ctrl+a drücken beim boot, aber da kann ich nicht so sonderlich viel anstellen mit den Platten.
Notfalls könntest du ein kleinen Shutdown-Script verwenden, dass dem Controller den Befehl zum Flushen des Caches gibt.
Das wäre natürlich was, wenn ich nur wüßte wie ich so etwas machen könnte. Ohje, ist das peinlich da will jemand ein Linux Server sauber aufsetzen und hat offensichtlich keine Ahnung von garnix :-( -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hermann wacker wrote:
Also Ich habe zwei SCSI Seagate Barracudas 34 GiB. sda (~37°C) ist besser gekühlt als sdb (~45°C). Beide hängen am gleichen Controller und am gleichen Kabel.
Welcher Controller?
Aus der kern.log: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 Nov 27 21:50:48 localhost kernel: <Adaptec 29160 Ultra160 SCSI adapter>
Okay, also ein Adaptec 29160, der mit dem Modul aic7xxx geladen wurde. Das sind zumindest schon einmal Standardkomponenten.
Nov 27 21:50:48 localhost kernel: aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Nov 27 21:50:48 localhost kernel: Nov 27 21:50:48 localhost kernel: (scsi0:A:0): 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Nov 27 21:50:48 localhost kernel: (scsi0:A:1): 40.000MB/s transfers (20.000MHz, offset 63, 16bit) Nov 27 21:50:48 localhost kernel: (scsi0:A:5): 40.000MB/s transfers (20.000MHz, offset 32, 16bit) Nov 27 21:50:48 localhost kernel: Vendor: SEAGATE Model: ST336607LW Rev: 0007 Nov 27 21:50:48 localhost kernel: Type: Direct-Access ANSI SCSI revision: 03 Nov 27 21:50:48 localhost kernel: Vendor: SEAGATE Model: ST336607LW Rev: 0007 Nov 27 21:50:48 localhost kernel: Type: Direct-Access ANSI SCSI revision: 03 Nov 27 21:50:48 localhost kernel: Vendor: HP Model: C5683A Rev: C111 Nov 27 21:50:48 localhost kernel: Type: Sequential-Access ANSI SCSI revision: 02
Hier komme ich etwas ins Schleudern. Der Controller ist ein U160, die Seagate ST336607LW ist sogar eine U320-Platte. http://www.seagate.com/cda/products/discsales/enterprise/tech/1,1084,541,00.... Die Logic würde eigentlich sagen, dass der Buss auf 160MB/s gesetzt sein sollte, nicht auf 40MB/s. Tu mir doch mal den Gefallen, und lasse den HP Surestore erst mal außen vor. Dann gehe mal in das Bios von dem Adaptec und schau dir mal an, wie die Geschwindigkeit für die beiden SCSI-Platten alleine eingestellt wurde. Wenn sie jetzt auf 160MB/s ausgehandelt wurde, dann setze besser einen zweiten SCSI-Controller herein für das Bandlaufwerk. Das würde ich dir auf jeden Fall raten. Ich gehe davon aus, dass du einen guten LVD-Terminator verwendet hast?
Dieses Verhalten, das sda aus dem Raid fliegt, kann ich immer durch reboot reproduzieren.
Das ist doch etwas wert. Finde doch mal raus, ob der Schreibcache der Platten aktiv ist. Wenn ja, dann deaktiviere ihn und teste aus, ob es imme r noch beim reboot zu Problemen kommt.
So, nach 30 minuten googlen habe ich leider nicht herausbekommen wie ich denn so etwas anstellen könnte, ich weiß jetzt nur das Linus Torvalds mal 2001 in einer Diskussion meinte das ide platten blöd sind, weil sie ATA FLUSH teilweise nicht kennen ;) Ne im ernst. Ich hab es mit sdparm versucht, aber ich blicke da schlicht nicht durch, ich weiß nicht mal mit welchem tool man überhaupt sehen kann was, wie und so welche Caches benutzt werden, hast du da einen Tip für mich?
Schau einfach mal ins Bios des Controllers und gehe auf die einzelnen Festplatten. Dort sollten die Optionen zu finden sein.
Ist das Problem dadurch gelöst, musst du zusehen, dass der Controller den Cache sauber auf die Platten leert vor dem Reboot. Ich sehe da eigentlich nur den Treiber und das SCSI-Bios als Möglichkeiten.
Zum Treiber, ähem, muß ich gestehen das mein System den Controller auf magische Weise einfach so benutzt hat. Ich hab keinen Schimmer wie der Treiber heißt und wo ich da irgendwas nachschauen oder beeinflussen könnte. :-s
Der Treiber ist heißt aic7xxx, mit lsmod kannst du nachschauen, welche Treiber geladen sind. Du kannst auch unter /proc/scsi/scsi nachschauen, was dort an Geräten steht. Wenn du das System von einer IDE-Platte bootest, dann kannst du, fall notwendig, auch versuchen, das Modul einmal selbst zu kompilieren. Vielleicht gibt es auch eine aktuelle Version für deine Distro zum Runterladen.
Wegen SCSI-Bios: meinst du da das Bios vom Controller? Das einzige das ich in diese Richtung kenne ist ctrl+a drücken beim boot, aber da kann ich nicht so sonderlich viel anstellen mit den Platten.
Ja, ich meine das Bios des Controllers. Im Augenblick habe ich leider keinen freien Adaptect 29160 zur Verfügung für Experimente. :-( Ich verwende ohnehin meist RAID-Controller, und dort sind die Optionen verfügbar.
Notfalls könntest du ein kleinen Shutdown-Script verwenden, dass dem Controller den Befehl zum Flushen des Caches gibt.
Das wäre natürlich was, wenn ich nur wüßte wie ich so etwas machen könnte. Ohje, ist das peinlich da will jemand ein Linux Server sauber aufsetzen und hat offensichtlich keine Ahnung von garnix :-(
Eines nach dem anderen. Vielleicht finden wir ja noch den Grund für das Auseinanderfliegen deines RAIDs. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Hermann, ich hatte exakt das selbe Problem, nur mit weitaus amateurhafter hardware (nForce2 onboard SATA Raid). Wie du schon bemerkt hast, baust du sda und sdb1 zu einem Raid zusammen. Bei mir war das genauso, der Fehler saß vor dem Bildschirm beim Partitionieren der Platten. Ich habe danach die Platten beide neu partitioniert - dann hatte ich tatsächlich sda1 und sdb1, mit denen das Raid auch den Reboot überlebt hat. grüße, teja Hermann wacker wrote:
Hallo Liebe Liste,
zum generellen Verständnis erstmal: das ist hier ja eine Liste für OpenSuse Benutzer. Das Problem das ich jetzt habe ist aber leider auf einer Debian Sarge, darf ich Probleme dazu trotzdem hier stellen? Ich denke mal dass das Problem eher nicht Distributionsabhängig ist. Naja ich stelle einfach mal die Frage, vielleicht findet sich die Antwort ja ganz einfach, wenn nicht dann reicht eine kurze Info, das so ein verhalten unerwünscht ist.
Also Ich habe zwei SCSI Seagate Barracudas 34 GiB. sda (~37°C) ist besser gekühlt als sdb (~45°C). Beide hängen am gleichen Controller und am gleichen Kabel. Ich habe ein Software Raid eingerichtet auf folgendem Weg:
1. cfdisk /dev/sd(a/b) -> jeweils den gesamten Platz in eine Partition gepackt. 2. reboot weil mdadm meckerte das sdb1, wo ich test weise ein raid eingerichtet hatte das 300 MiB groß war, nur 300 MiB groß ist. Das Problem ließ sich nicht mal damit beheben das ich die Platte herunterfuhr, ich mußte die ganze Kiste neustarten weil anscheinend der Kernel noch irgendwie die alten Partitionsdaten der Platte hatte (das hab ich mir so zusammengereimt aus einem Post im Internet). 3. mdadm --create --verbose /dev/md0 --level=raid1 -n2 /dev/sda1 /dev/sdb1 4. mit watch cat /proc/mdstat zuschauen wie die beiden Platten syncen. 5. zum Test einfach mal neustarten und schauen ob alles läuft. cat /proc/mdstat spuckt aus:
Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 scsi/host0/bus0/target1/lun0/part1[1] 35840896 blocks [2/1] [_U]
unused devices: <none>
Dann hab ich noch mdadm --detail /dev/md0 gefragt. Heraus kam:
/dev/md0: Version : 00.90.00 Creation Time : Tue Nov 28 05:33:29 2006 Raid Level : raid1 Array Size : 35840896 (34.18 GiB 36.70 GB) Device Size : 35840896 (34.18 GiB 36.70 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent
Update Time : Tue Nov 28 06:59:27 2006 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0
UUID : aae453e9:c76daf64:e9e44552:a55cde6f Events : 0.7
Number Major Minor RaidDevice State 0 0 0 0 faulty removed 1 8 17 1 active sync /dev/sdb1
Dieses Verhalten, das sda aus dem Raid fliegt, kann ich immer durch reboot reproduzieren. Dann kann ich mit mdadm /dev/md0 -a /dev/sda den rebuild prozess lostreten, mdadm --detail /dev/md0 meint dazu:
/dev/md0: Version : 00.90.00 Creation Time : Tue Nov 28 05:33:29 2006 Raid Level : raid1 Array Size : 35840896 (34.18 GiB 36.70 GB) Device Size : 35840896 (34.18 GiB 36.70 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent
Update Time : Tue Nov 28 21:52:15 2006 State : active, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1
Rebuild Status : 4% complete
UUID : aae453e9:c76daf64:e9e44552:a55cde6f Events : 0.8
Number Major Minor RaidDevice State 0 0 0 0 faulty removed 1 8 17 1 active sync /dev/sdb1
2 8 0 2 spare rebuilding /dev/sda
Allerdings wird das ganze wieder kaputtgehen wenn ich den Rechner neustarte. Ich meine im Grunde ist das kein Riesenproblem, denn der Server soll eigentlich nie neugestartet werden, aber ich vertraue einfach meinem Raid nicht, weil es nicht läuft wie es sollte. Hat jemand schon mal so ein komisches Verhalten gehabt? Oder mache ich schlicht etwas falsch?
Falls es jemand wundert (mich hat es jedenfalls gewundert): Ein mdadm /dev/md0 -a /dev/sda1 gibt mdadm: hot add failed for /dev/sda1: Invalid argument
nur mdadm /dev/md0 -a /dev/sda funktioniert.
Das sda hinüber ist bezweifle ich eigentlich, da der Server seit drei Monaten friedlich mit sda gearbeitet hat, sdb und sda zum gleichen Zeitpunkt gekauft wurden, daher wahrscheinlich aus der gleichen Produktionsmarge stammen und auch sonst ich einfach hoffe nur zu dumm zu sein um ein Raid aufzustellen.
Vielleicht noch hilfreiche Info: sda und sdb sind reine Datenplatten. gebootet wird von einer stinknormalen Western Digital 40GB Platte.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFbqZ8fYftu7iKDdoRAmDvAJ4uOet2qG9xnzcKBu1QcKjwX7u1zwCeJzFB C5sl778wOQLf3Nk9r9bin9Q= =YmS1 -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Hermann wacker -
Sandy Drobic -
Teja Philipp