Geschichte/Server/top1/2006-01-09: Unterschied zwischen den Versionen

Aus UUGRN
< Geschichte‎ | Server‎ | top1
K (format)
 
(kein Unterschied)

Aktuelle Version vom 9. April 2022, 14:46 Uhr

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 <-- 
…