Experten-Tipps

[Florian Lohoff]

On Fri, Mar 01, 2002 at 09:50:23PM +0100, Dominic Battre wrote:
> 
> Naja, es geht eben gerade darum, dass die User sich nicht damit 
> rumplagen müssen. Die stehen in den 5 Stunden unter ziemlichem Druck und 
> sollen sich nur auf die Aufgaben konzentrieren müssen ;)
> 

Andersherum - Woher weisst du bei scp/ssh wo die die dinger lokal
liegen haben ? Ich baue gerne in /var/tmp - Andere im homedir
andere unter /usr/src ...

> Sowas hatte ich erwartet... ;)
> 
> 1) Kommt trägt das die notwendigen Daten in den MBR ein?

/dev/hda - ist die GESAMTE platte - inklusive des MBR und partition
table.

> 2) Wo kommt die Netzwerkverbindung her? Dazu brauchst du ja schon ein 
> laufendes Linux...

Bootfloppy mit syslinux und nem kernel mit nfs-root/DHCP der
vom netz bootet und von demselben netzlaufwerk das dd macht - Insgesamt
eine arbeit von 1-2 Stunden ...

> aber die Idee ist evtl. gar nicht verkehrt... Man könnte zumindest, wenn 
> die Rechner einmal konfiguriert sind, die Partitionen lokal spiegeln 
> (nach /dev/hdb oder so). Aber trotzdem braucht man die Images auf dem 
> Netz...

Auch via nfs root booten und das ganze ins netz d.h. auf ein
netzlaufwerk schreiben.

> Nein, das ist keine Lösung. Wir forken ja um die Programme zu starten. 
> Hinterher stürzt uns noch unser Parent-Prozess ab. Dann fangen wir an, 
> 40 Teilnehmer x 3 Programme x 10 Testfälle manuell auszuwerten ;))
> 
> Ich habe es nicht ausprobiert, da ich gerade keine Kiste mit 2.2er 
> Kernel hier habe, aber prinzipiell sollte das unter 2.2 mit 
> setrlimit(RLIMIT_AS,...) schon gehen... Aber ich glaube, die haben bei 
> 2.4 den Speichermanager ausgetauscht...

Sollte nicht gehen - Andere idee - Warum nicht eine malloc library bauen
a la libefence z.b. und in der ein eigenes malloc accounting machen.
Sollte relativ einfach gehen und bei erreichen des limits einfach
ein SIGBUS/SIGSEGV ausloesen. Das ganze per LD_PRELOAD laden.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20020302/5f6e4af8/attachment.sig>