Geschichte/Server/top1/2006-01-09

Aus UUGRN
< Geschichte‎ | Server‎ | top1
Version vom 27. April 2013, 02:06 Uhr von Rabe (Diskussion | Beiträge) (Noch diverse technische Details zu möglichen Ursachen warum das RAID so schlecht auf den Ausfall reagiert haben könnte)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

01:30:21 <rabe> ich geh ins bett … 06:37:22 <rabe> morgen 07:45:07 <dwalin> moin … 16:30:17 <mile> rabe: btw, ich habe im Log von deinen Problemen mit top gelesen, wie sieht es denn damit mittlerweile aus? 16:45:55 <dwalin> mile: noch keine aenderung... ich werde heute abend mal schauen ob ich das pxe-notfallsystem in ffm einsatzfaehig bekomme, dann koennen wir remote wieder was tun 16:52:09 <rabe> mile: so ganz grob: kiste aufgehängt und eingeschaltet ... lief. idle ist dann eine platte ausgefallen, das RAID degraded weitergelaufen. ich habe dann auf die USB-Platte ein Backup gemacht, was auch für / /usr und /var funktioniert hat, bei /data ist dann die zweite platte auch ausgefallen, danach war erstmal der ofen aus, weil der controller sich den ausfall der platte nicht "gemerkt" hat, d.h. die platten waren nicht mehr sync, der controller hat aber genau da 16:52:36 <rabe> der grund, waurm die eine platte ausgefallen ist könnte einfach sein, dass der controller SATA-Mäßig nicht sauber unterstützt wird 16:53:16 <rabe> ich denke es wird darauf hinauslaufen, einen SATA-RAID-Controller zu kaufen und einzubauen 16:54:44 <rabe> das ärgerliche an der sache war, dass ich den server daheim schon ne weile recht intensiv laufen hatte 16:54:52 <rabe> und da nie was derartiges aufgetreten ist 16:56:04 <mile> Das ist so ein Adaptec-Dingsi, nicht? 16:56:20 <mile> Ist da irgendwas bekannt? Mal die FreeBSD-Mailinglisten durchsucht? 16:59:10 <rabe> also ... ich muss dazu noch grundlagenformusch betreiben ... 16:59:13 <rabe> forschung 16:59:21 <rabe> @work haben wir was ganz ähnliches derzeit 16:59:27 <rabe> andere hardware 16:59:45 <rabe> FreeBSD panic()t, wenn er versucht zu swappen 16:59:55 <rabe> dsa ist zwar bei 2GB RAM recht selten 17:00:00 <rabe> aber passiert 17:00:21 <rabe> die fehlermeldungen in der console deuten darauf hin, dass er ewisse blöcke im RAID nicht schreiben kann 17:00:57 <rabe> mile: ich war das ganze WE nicht daheim, ich kümmer mich darum, sobald ich daheim luft habe ... 17:01:35 <rabe> ärgerlicherweise habe ich nichtmal die Ausgabe von "lspci -vvv" zur hand. iirc 17:02:39 <mile> Naja, eilt ja erstmal auch nicht. 17:02:40 <rabe> ah, doch ... 17:02:41 <rabe> http://rabe.uugrn.org/FreeBSD/top.uugrn.org/pciconf-vvl.txt 17:02:53 <rabe> habe solche relevanten sachen von allen möglichen maschinen 17:03:21 <rabe> http://rabe.uugrn.org/FreeBSD/top.uugrn.org/dmesg.boot 17:04:03 <rabe> atapci1@pci0:31:2: class=0x01048f card=0x34308086 chip=0x25b08086 rev=0x02 hdr=0x00 17:04:06 <rabe> vendor = 'Intel Corporation' 17:04:08 <rabe> device = '6300ESB Serial ATA Controller (RAID mode)' 17:04:11 <rabe> class = mass storage 17:04:13 <rabe> subclass = RAID 17:11:27 <rabe> http://archives.vault9.net/arc/mailing/freebsd-hackers/0878.html <-- …