[Eisfair] Noch mal Eisfair(64) und Proxmox (Perfomance)

[Kay Martinen]

Am 05.03.2019 um 01:09 schrieb Hilmar Böhm:
> Am 04.03.19 um 22:33 schrieb Thomas Bork:
>> Am 03.03.2019 um 22:53 schrieb Hilmar Böhm:
>>
>>> Zu Eisfair:
>>> Könnte man nicht bei "Waiting for SCSI/SATA/PATA devices coming up"
>>> die Wartezeiten (zumind.) halbieren 10 -> 5 Sek. Bei Eisfair-VM's
>>> gibt es praktisch keine Wartezeiten mehr für die vHD's.
>>
>> Diese Delays stammen noch aus den Zeiten mit Kernel 2.6.x. Seitdem hat
>> niemand mehr getestet, ob mit neuerem Kernel mit kürzeren Denkpausen
>> noch alles funktioniert.
>>
>> Auszug aus dem Kernel-Install-Skript (Funktion zur Erzeugung der
>> initramfs):
>> ...
>> ...
>>
>>        # always waiting for devices coming up
>>        {
>>        echo '/bin/echo -e "\033[32m\033[49mWaiting for SCSI/SATA/PATA
>> devices coming up ...\033[0m"'
>>        echo '/bin/sleep 10'
>>        } >>$initrd_mount/init
>>    fi
>>
>>
>> Wenn sich also jemand die Arbeit macht, mal wieder alle möglichen
>> Installationen mit einem kürzeren Delay durchzutesten (Installation
>> und darauf folgenden Boot von und auf einen langsamen USB-1-Stick,
>> Installation auf ein gemischtes Array aus IDE-, SCSI- und
>> SATA-Platten, die an verschiedenen Controllern unterschiedlich lange
>> benötigen, um alle bereit zu sein usw.) und das alles auf Hardware,
>> die nicht aus den letzten 5 Jahren stammt:
>> Dann können wir das gerne mal ändern.
>> Wer macht es? Du?
>>
> Wenn Du mich meinst: Nein!
> (Keine Zeit, bin (in diesem Fall) nur Anwender.)

Na und, Ich auch. Aber vielleicht war das ein Angebot von Thomas die
einen kernel mit kürzerem Delay zu schicken. Du must ihn dann bei dir
allerdings installieren, aktivieren, booten und sehen ob wirklich alles
immer gefunden und eingebunden wird.

> Zu dem Block " #always waiting for devices coming up"
> kann ich nur sagen, dass eine VM auf einem Host läuft, der i.d.R. einen
> virt. Spreicher (vHD) für die VM bereits zur Verfügung hat, wenn die VM
> auf ihm gestartet wird. Also keine Wartezeiten erforderlich. Warum nicht
> einfach diese 10 Sek. sleep weglassen?

Du verstehst da glaube ich noch etwas nicht richtig. Das wäre eine
Optimierung hin zu VM-Betrieb. Und weil der kernel nicht nur für VMs
taugt, sondern insbesondere auch für Reale ältere HW mit realen
Verzögerungen beim Hochfahren. So kann es dir z.B. passieren das dein
root-dev auf einer IDE oder S-ATA Platte noch schnell gefunden würde,
wenn du aber einen SCSI-Controller hast und der kein RAID macht, die
Platten aber an einer SCA-Backplane hängen und auf Soft-start
eingestellt sind... dann mußt du dich drauf verlassen das keiner den
Controller in seinem Setup umstellte. Denn dann ist DER es der jeder
einzelnen Platte erst ein Start Signal schicken muß. Bis die
Hochgelaufen sind kann das etliche Sekunden dauern. Üblicherweise macht
der das Sequenziell, aber die PlattenID kann er m.E. auch vorher schon
lesen. Die Platten sind also evtl. noch am Hochdrehen, der Controller
durch damit und das OS startet.... und findet diese nicht weil sie noch
nicht Ready sind. Und dann könnte es auch sein das man keine U320 Disk
hat, sondern eine SCSI-1 (oder emulator) die evtl. grad mal 5 MB/sek
liefern kann. Dann kann es noch länger dauern.

Ich habe damals z.b. eine SyQuest Wechselplatte mit 66 MB als Bootmedium
ausprobiert. Die hing an einem einfachen FAST-SCSI Kontroller und war
dennoch schnarchlangsam. Das war allerdings noch DOS. Ich zweifele
Ernsthaft ob die von einem EIS beim Boot überhaupt gefunden werden
würde. Die Braucht nach einlegen und aktivieren ca. 20 Sekunden bis sie
überhaupt brauchbar ist. Und, je nach Konfig kann man so was als
Wechsellaufwerk(=Floppy) oder als Festes Laufwerk(=Disk) betreiben. Bei
letzterem könnte sie nicht fest gemountet werden wenn sie nicht bereit ist.

> Andere (Server-)Systeme anderer Distributionen stellen heutzutage fest,
> ob ihr Kernel in einer VM läuft. 
> Wollte nur zeigen, dass es geht. 

Brauchst du nicht zeigen, ist bekannt.

Das kann der Kernel selbst am besten und ganz allein feststellen.
Aber der Nebeneffekt eines Verkürzten Delays könnte sein das der kernel
auf Echter HW nicht mehr Jedes Laufwerk findet und das noch mehr Ärger
Produziert. Und das nur weil du ein Problem mit 10 Sekunden Warten hast.
Nee, danke. Da erWARTEst du etwas zu viel für meinen Geschmack.


> Aber wenn ich der einzige bin, dem das
> aufstößt und wenn das bei einem Server keine Rolle spielt (oder ich nur
> "auf hohem Niveau jammere"), dann lassen wir es halt so. wie ist...

Damit hätte ich kein Problem. :-)

Kay

-- 
Sent via SN (Eisfair-1)