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

[Hilmar Böhm]

Hallo Kay,

Sei mir bitte nicht böse, aber ich glaube, Du hast mit nicht verstanden.

Gruß. / Hilmar.


Am 05.03.19 um 16:31 schrieb 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
>