Another Tuesday, another planned outage. We did the usual database compression and backup but it still took a long time as we're bloated with 2 million extra results waiting to be assimilated.

No big deal there, but of course we're still mired in the thumper projects. It's becoming a two-weeker (since the original crash the Friday before last). Remember we're fighting on two fronts: rebuilding the root drive RAID and rebuilding the pulse table. Starting with the former, all we (thought we) had left to do was install grub on one of the two bootable drives (even though the weird drive numbering causes grub to read the actual kernel image off a third, non-bootable drive). Before launching into that I rebooted the system just to make sure everything was working.

This system has very large ext3 file systems, and so I used tune2fs a while back to prevent a long (6-8 hour) forced file system check every 180 days (the default). Unbeknownst to us, it would *also* force a check every N mounts. So I was very displeased to find the system going through a round of forced checks when all I wanted to do was quickly reboot the thing. I was just going to let it go, but after a half hour I got sufficiently annoyed to just halt the check (gracefully) and re-tune2fs'ed to prevent this from happening again.

And upon coming up I was further displeased to find the only root drive (of the three) that appeared in the RAID was the one in the non-bootable slot. We're stumped as to why. Well, even though this RAID was seriously degraded, we powered down, did the planned drive swapping and brought the system up. Even though drives were swapped the only root drive this time in the RAID was the (new) one in the non-bootable slot. Fine. I'm pretty much of the opinion we need to reinstall the OS on this point to clean everything up, but until that happens we have some (oddly long) drive resyncs to un-degrade the RAID. Of course, this will all fail again upon next boot as far as I can tell.

Meanwhile, the pulse table reload that started yesterday failed last night. Since we have redundant database servers now, the informix engine is sensitive to anything that may bring the primary/secondary systems out of whack. This includes really long queries, like the one we started yesterday to copy 500 million pulses from one table to another. Back to square one. Jeff wrote a script that breaks this one query up into many smaller ones, thus hopefully circumventing any "long query" issues. We estimate this will be done Thursday sometime.

I did start up one assimilator - the trickery I mentioned yesterday (to let assimilation run alongside pulse table insertions) does work, however as the pulse table gets populated it eats up a lot of database locks, and the assimilator can barely get an insert in edgewise. In any case, I found a rich source of stuff to move off the workunit storage server, so at least that bottleneck will be temporarily alleviated.

Oh, yeah - end of the month, so that's the end of the current thread title theme. I think the only person who came close to describing the theme was QuietDad yesterday (apologies if others got it earlier). Anyway, the official theme was: Apple II hackers/game programmers who, as a budding young programmer myself in the 70's/80's, I thought were super heroes such that I fondly honor their names (real or otherwise). It takes a real game programmer to do *everything* - not just the game logic but also the design, the graphics, the animation, the sound, the music... and do it all in machine language (and 6 colors, including black and white, in 280x192 "hi-res" graphics).

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

kann das mal einer in deutsch übersetzen?


can someone translate in german?

kann das mal einer in deutsch übersetzen?


can someone translate in german?

I'll try :)
(edit in this post will follow)

---

Robi

have you ever thought about installing opensolaris on this thumper? those raid/bootdisk/fsck hassle cry for zfs as solution. or maybe nexenta, if you more comfortable with a linux like userland.

---

kann das mal einer in deutsch übersetzen?


can someone translate in german?

Ein anderer Dienstag, eine andere geplante Störung. Wir taten die übliche Datenbankkompression und -unterstützung, aber es dauerte noch eine lange Zeit als we' Re aufgeblasen mit 2 Million Extraresultaten, die warten angepasst zu werden. Keine große Sache dort, aber selbstverständlich we' Renoch verstricktes in den Klopferprojekten. It' werdenes s ein two-weeker (seit der ursprüngliche Abbruch der Freitag vor Letztem). Erinnern Sie sich an we' Rekämpfen auf zwei Frontseiten: die Wurzel umbauend, fahren Sie RAID und den Wiederaufbau der Impulstabelle. Beginnend mit dem ehemaligen, war alles, das wir (gedacht wir) verlassen hatten, um zu tun, Made auf einen der zwei startbaren Antriebe anzubringen (obwohl die sonderbare Antriebsnumerierungs-Ursachenmade, zum des tatsächlichen Kernbildes weg von einer dritten, des non-bootable Antriebs zu lesen). Bevor ich in das startete, startete ich das System gerade neu, um sicherzustellen, dass alles arbeitete. Dieses System hat sehr große ext3 Dateisysteme und also verwendete ich tune2fs, das eine Weile zurück zu eine lange (Stunde 6-8) gezwungene Dateisystemüberprüfung alle 180 Tage verhindern (die Rückstellung). Ohne das Wissen von uns wurde sie *also* Kraft eine Überprüfung jedes n-Einfassungen. So wurde ich sehr missfallen zu finden, dass das System, das einen Umlauf der Zwangsüberprüfungen durchläuft, wenn alle, die ich tun wollte, schnell Neustart die Sache war. Ich war gerade im Begriff, ihn gehen zu lassen, aber, nachdem eine halbe Stunde, die ich genug gestört erhielt, um die Überprüfung (würdevoll) und re-tune2fs' gerade anzuhalten; Ed, zum zu verhindern, dass dieses wieder geschieht. Und nach aufkommend wurde mir weiter missfallen zu finden, dass der einzige Wurzel-Antrieb (der drei) der im RAID erschien, der im non-bootable Schlitz war. We' Re stumped hinsichtlich warum. Gut obwohl dieser RAID ernsthaft vermindert wurde, schielten wir ab, taten den geplanten austauschenden Antrieb und holten das System oben. Obwohl Antrieben der einzige Wurzel-Antrieb ausgetauscht wurden, war dieses mal im RAID (neue) das in non-bootable kerben. Fein. I' m ziemlich genau der Meinung, die wir das OS in diesem Punkt wieder installieren müssen, um alles aufzuräumen, aber, bis der geschieht, haben wir etwas (ungewöhnlich langer) Antrieb resyncs, zum des RAID UNO-zu vermindern. Selbstverständlich wird dieses alles Ausfallen wieder nach folgender Aufladung, insoweit ich sagen kann. Unterdessen fiel das Impulstabellenumladen, das gestern begann, gestern Abend aus. Da wir überflüssige Datenbankbediener jetzt haben, ist die informix Maschine für alles empfindlich, das die Primär-/Sekundärsysteme aus Whack heraus holen kann. Dieses schließt wirklich lange Fragen, wie die ein, die wir gestern begannen, 500 Million Impulse von einer Tabelle zu anderen zu kopieren. Zurück zu Quadrat eins. Jeff schrieb einen Index, der diese eine Frage oben in viele kleineren bricht und so hoffnungsvoll verhindert jedes mögliches " langes query" Ausgaben. Wir schätzen dieses werden getan Donnerstag einmal. Ich begann oben einen Assimilator - der Schwindel, den ich erwähnte, dass gestern (Assimilation neben Impulstabelleneinfügungen laufen lassen) arbeitet, gleichwohl bevölkerte, da die Impulstabelle erhält, es isst herauf viele Datenbankverschlüsse und der Assimilator einen Einsatz kaum innen erhalten kann edgewise. Auf jeden Fall fand ich eine reiche Quelle des Materials, um weg vom workunit Speicherbediener umzuziehen, so, mindestens dass Engpass vorübergehend vermindert wird. Oh, yeah - Ende des Monats, damit ' s das Ende des gegenwärtigen Gewindetitelthemas. Ich denke, dass die einzige Person, die nah an der Beschreibung kam, das Thema QuietDad gestern war (Entschuldigungen, wenn andere es früher erhielten). Sowieso war das amtliche Thema: Häcker Apple-II/Spielprogrammierer die, als knospender junger Programmierer selbst im 70' s/80' s, dachte ich war Superhelder so, dass ich vernarrt ihre Namen ehre (real oder anders). Es nimmt einen realen Spielprogrammierer, um *everything* zu tun - nicht gerade die Spiellogik aber auch den Entwurf, die Grafiken, die Animation, der Ton, die Musik… und tut ihn allen in Maschinensprache (und in 6 Farben, einschließlich Schwarzweiss, im " 280x192; hallo-res" Grafiken). - Matt

---

BOINC Wiki . . .

Science Status Page . . .

Anyway, the official theme was: Apple II hackers/game programmers who, as a budding young programmer myself in the 70's/80's,

Hacker and programmer were synonomous in the 70's.....

---

Of course, this will all fail again upon next boot as far as I can tell.

Always the optimist, eh Matt?

---

Calm Chaos Forum...Join Calm Chaos Now

Of course, this will all fail again upon next boot as far as I can tell.

Always the optimist, eh Matt?

Yes, he is a realist.

---

BOINC WIKI

sounds like you are trying to use software raid in linux to miror your boot partition, which you by now know that isn't supported. in the event of a failure you will have to reconfigure your drives to be able to boot any way. i wouldn't worry about grub, you can always rescure/restore it from the boot dvd.

---

kann das mal einer in deutsch übersetzen?


can someone translate in german?

I'll try :)

Deutsche Ãœbersetzung:

Wieder ein Dienstag, wieder ein geplanter Unterbruch. Wir haben die übliche Datenbank-kompression und Datensicherung ausgeführt, und trotzdem dauerte es lange, da wir mit 2 Millionen zusätzlichen Resultaten, welche für die Angleichung (Assimilation) warten, übersättigt sind.

Dies ist zwar kein Problem, jedoch sind wir immer noch mit den Thumper Projekten belastet. Es ist mittlerweile ein Zwei-Wöchiger geworden (Den ersten Absturz war Freitag vorletzter Woche). Vergisst nicht, wir kämpfen an zwei Fronten: die Wiederherstellung des root drive RAID und die Wiederherstellung der Puls Tabelle. Die Erstere, (wir dachten) alles was wir noch zu tun hätten, sei grub auf einer der zwei bootfähigen drives zu installieren (trotz der eigenartigen drive Benennung, welche grub veranlasst den Kernel von einem dritten, nicht-bootfähigen drive zu lesen). Bevor wir dies in Angriff nahmen, habe ich das System frisch gestartet, um sicher zu gehen, dass alles funktioniert.

Dieses System hat sehr grosse ext3 Dateisysteme, deshalb benutzte ich vor geraumer Zeit tune2fs, um lange (6-8 stündige) wiederkehrende gewaltsame Dateisystem Überprüfungen alle 180 Tage zu umgehen. Es war uns jedoch unbewusst, dass eine Überprüfung *auch* alle X Monate gewaltsam durchführt wird. Somit war ich äusserst verdrossen, als ich bemerkte, dass das einzige root drive (von den dreien) welches im RAID auftauchte, dasjenige im nicht bootfähigen Einschub war. Wir verstehen immer noch nicht wieso. Naja, trotzdem dieses RAID unmöglich degradiert ist (wirklich ein resync braucht), haben wir das System heruntergefahren, den geplanten drive-Austausch ausgeführt und das System wieder hochgefahren. Trotz des drive-Austausches, war das einzige root drive im RAID dieses mal das (neue) im nicht-bootfähigen Einschub. Ich denke, die einzige Lösung ist das OS frisch zu installieren, um ein sauberes System zu haben wo alle Probleme bereinigt sind, Jedoch bevor dies geschieht, haben wir (eher längere) drive resyncs vor uns, um das RAID wieder auf Vordermann zu bringen. Klar, dies alles wird wieder beim nächsten Neustart in die Hose gehen.

Mittlerweile, das wiederladen der Puls Tabelle welche gestern gestartet wurde, hat in der Nacht abgebrochen. Da wir jetzt redundante Datenbank Server haben, ist die Informix Maschine äusserst wählerisch mit Transaktionen, welche das Haupt-/Zweitsystem aus dem Gleichgewicht bringen könnte. Dies bedeutet auch sehr lange Transaktionen, wie diejenige die wir gestern aufsetzten, um 500 Millionen Pulse von einer Tabelle zur anderen zu kopieren. Zurück zum ersten Feld. Jeff hat nun die Transaktion in kleinere Einheiten umgeschrieben, welche dieses Problem umgehen sollte. Wir nehmen an, dies sei dann irgendwann Donnerstags beendet.

Ich habe einen Assimilator aufgestartet - der trick den ich Gestern beschrieb (Assimilation neben Puls Tabellen Einfügungen laufen zu lassen) funktioniert, jedoch desto mehr puls-tabellen Einträge, umso mehr Datenbank sperrungen, und der Assimilator hat Probleme um Einträge zu machen. Ich habe jedoch Platz gefunden um dieses Problem zur Zeit zu umgehen.

Ah, jawohl - Monats Ende, dies ist auch das Ende des Titel Themas. Ich glaube die einzige Person welche der Beschreibung des Themas nahe kam war gestern QuietDad (Verzeihung falls andere es eher herausfanden). Das Thema war: Apple II Hacker/Spiele Programmierer welche, da ich selbst ein junger Programmierer in den '70/'80 war, meiner Ansicht Superhelde waren, wobei ich deren Namen Ehre (wahre Namen oder andere /Nicknamen/). Es braucht ein wahrer Programmierer um *alles* - nicht nur die Spiel Logik sondern auch die Gestaltung, die Grafik, die Animation, die Klang Effekte, die Musik... und all das in Maschinensprache (und 6 Farben inklusive Schwarz und Weiss, in 280x192 "Hochauflösung" Grafik)

---

Robi

Dr. C.E.T.I., you are funny :)
I tried to read it.... lots of gobbeldygook ;)

---

Robi

Dr. C.E.T.I., you are funny :)
I tried to read it.... lots of gobbeldygook ;)

TRANSLATE:

Tuesday, planned interruption. We implemented the usual data base compression and data protection, and nevertheless it lasted for a long time, since we with 2 million additional results, which wait for the adjustment (assimilation), are surfeited. This is no problem, however we are still burdening with the Thumper projects. It became meanwhile a two-week (the first crash was Friday of the last but one week). Does not forget, we fight at two fronts: the re-establishment of the root drive RAID and the re-establishment the pulse table. The first, (we thought) everything which we to still do would have, is dug on one of the two boatable drives to install (despite the strange drive designation, which dug arranges the Kernel of third to read non-boatable drive). Before we tackled this, I had freshly started the system, in order to go surely that everything functions. This system has very large ext3 of file systems, therefore I used before some time tune2fs, in order to go around for a long time (6-8 hour) recurring file system by force examinations every 180 days. It was however unconscious us that an examination accomplishes *auch* all X months by force becomes. Thus I was extremely verdrossen, when I noticed that the only root drive (of the three) which in the RAID emerged, that in the not boatable module was. We do not understand yet why. Naja, although this RAID is not possibly degradiert (really resync needs), has we the system driven down, implemented the planned drive exchange and again raised the system. Despite the drive exchange, the only root was drive in the RAID of this times (new) in the non-boatable module. I think, the only solution am the OS freshly to be installed, in order to have a clean system where all problems am settled, however before this happens, have we (rather longer) drive resyncs before us, in order to bring the RAID to preceding endorser. Clearly, all of this will go again with the next restart into the trousers. Meanwhile, which again-load the pulse table which yesterday one started, has at the night broken off. Since we have now redundant data base server, the Informix machine is extremely discriminating with transactions, which the main/secondary system from the equilibrium could bring. This meant also very long transactions, how that which we yesterday put on, in order to copy 500 million pulses of a table on the other hand. Back to the first field. Jeff rewrote now the transaction into smaller units, which this problem should go around. We accept, this are then sometime Thursday terminated. I started a Assimilator - the trick which I described yesterday to let run (assimilation beside pulse tables insertions) functioned, however the more pulse tables of entries, all the more data base blockages, and the Assimilator has problems around entries to make. I have to go around however place found around this problem at present. Ah, jawohl - month end, this is also the end titles of the topic. I believe the only person which to the description of the topic close came was yesterday QuietDad (pardon if others found it out rather). The topic was: Apple II hacker/play programmer which, there I a young programmer into the ' 70/' 80 was, my opinion Superhelde was, whereby I their name honour (names or other /Nicknamen/ protect). It needs a true programmer over *alles* - not only the play logic but also the organization, which diagram, which animation, which sound of effects, the music… and all in machine language (and 6 colors inclusive black and white, " in 280x192; Hochauflösung" Diagram)

---

BOINC Wiki . . .

Science Status Page . . .

Is this the reason why I'm having a bit of trouble getting new units?

When I check the Messages tab I keep getting the red, "Message from server: (Project has no jobs available)" for a day or 2, maybe 3, which I found a bit unusual. I didn't think we'd ever run out of work units!

Thanks,
Garry....!

---

~~~~~~~~~~~~~~~~~~~~~~~~
www.drgnlord.com
~~~~~~~~~~~~~~~~~~~~~~~~

This body holding me
Reminds me of my own mortality.
Embrace this moment.
Remember, we are eternal.
All this pain is an illusion.
*** (Maynard James Keenan - TOOL) ***

New workunit creation rate is down in the pits atm. Is this due to server resources being clogged with the pulse table reload or the RAID resync?

---

You will be assimilated...bunghole!

Is this the reason why I'm having a bit of trouble getting new units?

When I check the Messages tab I keep getting the red, "Message from server: (Project has no jobs available)" for a day or 2, maybe 3, which I found a bit unusual. I didn't think we'd ever run out of work units!

Thanks,
Garry....!

The last work download to this computer was at 11:30pm PDT on the 28th (7:30 UTC on the 29th); almost exactly three days ago. I get the same message from the server at varying frequencies. Have been suspending network activity about 3/4 of the time. I wonder if anyone is playing Freerice.

---

keep telescopic listening devices aimed at the Zenith of the Horizon

4:15 in the A.M. here. Just woke up with a revelation..maybe. I've been playing with Linux for a while now, but messing with tune2fs is something I have not done. I do remember something about fstab though. At the end of the line, I think the default is "1 2" for the last two values. I don't feel like looking it up at the moment, but it has something to do with checking the file system. I know "0 0" is supposed to disable FS integrity verification. Could that be of any use now? I mean, you went and modified tune2fs already, but it could just be as simple as changing two values in fstab.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

. . . for those that haven't seen this Post:

March 24, 2009 <--- click me

We are currently managing several problems with the science database server. The database will be okay, but it is currently offline. It was take a while before we are fully back up and running normally. In the meantime we will mostly be unable to create new workunits, so expect your clients to run idle for the next few days (unless you are running other BOINC projects!)

---

BOINC Wiki . . .

Science Status Page . . .

Ach meine Fresse, beim übersetzen habe ich völlig ein paar linien übersprungen!!! 'Tschuldigkeit :)

Deutsche Ãœbersetzung:

Wieder ein Dienstag, wieder ein geplanter Unterbruch. Wir haben die übliche Datenbank-kompression und Datensicherung ausgeführt, und trotzdem dauerte es lange, da wir mit 2 Millionen zusätzlichen Resultaten, welche für die Angleichung (Assimilation) warten, übersättigt sind.

Dies ist zwar kein Problem, jedoch sind wir immer noch mit den Thumper Projekten belastet. Es ist mittlerweile ein Zwei-Wöchiger geworden (Den ersten Absturz war Freitag vorletzter Woche). Vergisst nicht, wir kämpfen an zwei Fronten: die Wiederherstellung des root drive RAID und die Wiederherstellung der Puls Tabelle. Die Erstere, (wir dachten) alles was wir noch zu tun hätten, sei grub auf einer der zwei bootfähigen drives zu installieren (trotz der eigenartigen drive Benennung, welche grub veranlasst den Kernel von einem dritten, nicht-bootfähigen drive zu lesen). Bevor wir dies in Angriff nahmen, habe ich das System frisch gestartet, um sicher zu gehen, dass alles funktioniert.

Dieses System hat sehr grosse ext3 Dateisysteme, deshalb benutzte ich vor geraumer Zeit tune2fs, um lange (6-8 stündige) wiederkehrende gewaltsame Dateisystem Überprüfungen alle 180 Tage zu umgehen. Es war uns jedoch unbewusst, dass eine Überprüfung *auch* alle X Monate gewaltsam durchführt wird. Somit war ich äusserst verdrossen, als ich bemerkte,

dass das System eine solche Überprüfung durchführte, trotz meines gewollten schnellstartes. Ich hätte es gehen lassen, aber nach einer halben Stunde war ich so verärgert, dass ich die Überprüfung (gnädig) abbrach, und tune2fs so einstellte, dass sies nicht wieder vorkommen würde.

Als dann das System hoch kam, war ich ebenfalls etwas verärgert, als ich bemerkte,

dass das einzige root drive (von den dreien) welches im RAID auftauchte, dasjenige im nicht bootfähigen Einschub war. Wir verstehen immer noch nicht wieso. Naja, trotzdem dieses RAID unmöglich degradiert ist (wirklich ein resync braucht), haben wir das System heruntergefahren, den geplanten drive-Austausch ausgeführt und das System wieder hochgefahren. Trotz des drive-Austausches, war das einzige root drive im RAID dieses mal das (neue) im nicht-bootfähigen Einschub. Ich denke, die einzige Lösung ist das OS frisch zu installieren, um ein sauberes System zu haben wo alle Probleme bereinigt sind, Jedoch bevor dies geschieht, haben wir (eher längere) drive resyncs vor uns, um das RAID wieder auf Vordermann zu bringen. Klar, dies alles wird wieder beim nächsten Neustart in die Hose gehen.

Mittlerweile, das wiederladen der Puls Tabelle welche gestern gestartet wurde, hat in der Nacht abgebrochen. Da wir jetzt redundante Datenbank Server haben, ist die Informix Maschine äusserst wählerisch mit Transaktionen, welche das Haupt-/Zweitsystem aus dem Gleichgewicht bringen könnte. Dies bedeutet auch sehr lange Transaktionen, wie diejenige die wir gestern aufsetzten, um 500 Millionen Pulse von einer Tabelle zur anderen zu kopieren. Zurück zum ersten Feld. Jeff hat nun die Transaktion in kleinere Einheiten umgeschrieben, welche dieses Problem umgehen sollte. Wir nehmen an, dies sei dann irgendwann Donnerstags beendet.

Ich habe einen Assimilator aufgestartet - der trick den ich Gestern beschrieb (Assimilation neben Puls Tabellen Einfügungen laufen zu lassen) funktioniert, jedoch desto mehr puls-tabellen Einträge, umso mehr Datenbank sperrungen, und der Assimilator hat Probleme um Einträge zu machen. Ich habe jedoch Platz gefunden um dieses Problem zur Zeit zu umgehen.

Ah, jawohl - Monats Ende, dies ist auch das Ende des Titel Themas. Ich glaube die einzige Person welche der Beschreibung des Themas nahe kam war gestern QuietDad (Verzeihung falls andere es eher herausfanden). Das Thema war: Apple II Hacker/Spiele Programmierer welche, da ich selbst ein junger Programmierer in den '70/'80 war, meiner Ansicht Superhelde waren, wobei ich deren Namen Ehre (wahre Namen oder andere /Nicknamen/). Es braucht ein wahrer Programmierer um *alles* - nicht nur die Spiel Logik sondern auch die Gestaltung, die Grafik, die Animation, die Klang Effekte, die Musik... und all das in Maschinensprache (und 6 Farben inklusive Schwarz und Weiss, in 280x192 "Hochauflösung" Grafik)

---

Robi

I have read your post several times and have absolutely no idea what's going on apart from the fact that it sounds painful.

I wish you the best of luck with it all and hope you get it back up and running again soon.

---

@ KWSN Sir Clark

Hey.. your 1st language is english? ;-D


@ all

Someone could say when we could get new WUs for our rigs?

---