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

[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
> 
> Hier wird bei Verwendung von usb-storage (also z.B. bei Installation auf einen USB-Stick) nach Laden des Moduls 6 Sekunden 
> gewartet. Wie man dem Kommentar entnehmen kann, war damals der Zeitraum, den der Kernel dem Modul einräumt, bevor angeschlossene 
> Medien bereit sind, 5 Sekunden lang. Das ist inzwischen nicht mehr so:
> 
> modprobe usb-storage
> pvscsi # cat /sys/module/usb_storage/parameters/delay_use
> 1
> 
> Inzwischen gibt der Kernel dem Modul nur noch 1 Sekunde Zeit, Medien zu finden.
> 
> Das Delay unten von 10 Sekunden habe ich damals durch Ausprobieren bestimmt. Damit lief dann in _jedem Fall_ alles fehlerfrei.
> 
> 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.)

USB-Storage verwende ich nicht für VM's.

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?

Andere (Server-)Systeme anderer Distributionen stellen heutzutage fest, ob ihr Kernel in einer VM läuft. Es gibt genügend freie 
Software - sicherlich auch für BASH/SH-Scripte, die diese Information liefern kann. In diesen Falle sind solche langen 
Wartezeiten nicht notwendig.

Beispiele (aus VM'S):

1. Debian 9: Journalmeldungen (Auszug):
	Mär 04 09:33:13 kmrzmp kernel: Booting paravirtualized kernel on KVM
	...
	Mär 04 09:33:13 kmrzmp systemd[1]: Detected virtualization qemu.
(Stör Dich nicht an systemd, die obere Meldung stammt vom Kernel)

2. Antergos_Minimal (ArchLinux basiert): Journalmeldungen (Auszug):
	Mär 04 23:46:28 antimin kernel: Booting paravirtualized kernel on KVM
	...
	Mär 04 23:46:29 antimin systemd[1]: Detected virtualization kvm.
	Mär 04 23:46:29 antimin systemd[1]: Detected architecture x86-64.
(Das ist das System das auf meinem Debian KVM-Host in 6 Sekunden auf 100 ist! :-)

3. Alpine Linux, Virt-Kernel, V3.9.2
	Keine entsprechende Meldung in 'messages'/dmesg,
	Aber vHD (sda, virtio-scsi) wird sehr schnell, ohne Wartezeiten gemountet.

Wollte nur zeigen, dass es geht.  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...

/ Hilmar.