Festplattentreiber - VIRTIO oder SCSI?

franc · Jun 15th 2019

Hallo

ich habe seit 2015 einen alten root Server L SATA v6 den ich von 14.04 auf 18.04 Ubuntu upgraden will, siehe:

Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

Im Rahmen der vorherigen Aufräumarbeiten sehe ich, dass im SCP unter: Medien > Festplatte der Festplattentreiber auf VIRTIO steht.

Man kann das ändern auf SCSI, was scheints empfohlen wird:

Bildschirmfoto 2019-06-15 um 07.35.41.png

Kann ich das gefahrlos umstellen oder birgt das ein Risiko?

Es wird ja davor gewarnt, aber auch gesagt, dass der empfohlene Treiber genutzt werden soll.

Danke für Tipps.

Gruß franc

Paul · Jun 15th 2019

Schau dir vorher unbedingt mal deine "/etc/fstab" und vielleicht auch die "/etc/default/grub" an, wie dort die Block Devices angesprochen werden. Wenn du dort etwas wie "/dev/vdaX" siehst, müsstest du das in /dev/sdaX ändern, sonst wird dein System nach dem Neustart nicht mehr booten (Im Falle der grub config bitte nicht vergessen, die grub.cfg neu erstellen zu lassen). Das dürfte wohl der größte Stolperstein werden.

Ansonsten viel Erfolg beim Upgrade! Der Wechsel von upstart auf systemd wird sicherlich auch nicht ganz trivial sein. Daher könnte man durchaus überlegen, ob man nicht zunächst das Upgrade auf 16.04 durchführt und dann erst auf 18.04 wechselt. Aber das musst du entscheiden.

Achja, stelle den Festplattentreiber am besten vor(!) dem Upgrade um und überprüfe, dass das System wieder sauber startet

SCD · Jun 15th 2019

Besser sind die UUIDS:

# blkid

Code

/dev/sda1: UUID="12b31a3c-ec0d-4b7d-be81-dd452fc3105e" TYPE="ext4" PARTUUID="a88deea1-01"
/dev/sda2: UUID="da056ebe-49fe-412d-83e2-1436dec92676" TYPE="swap" PARTUUID="a88deea1-02"

Wird zu:

Code

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                                 <mount point>   <type>  <options>                               <dump>  <pass>
UUID=12b31a3c-ec0d-4b7d-be81-dd452fc3105e       /               ext4    usrquota,grpquota,errors=remount-ro     0       1
UUID=da056ebe-49fe-412d-83e2-1436dec92676       none            swap    sw                                      0       0

Wenn das System danach nicht startet kann man einfach wieder auf VIRTIO zurückstellen.

franc · Jun 16th 2019

Ich habe es noch zurück gestellt, zugunsten des Systemupgrades, das mir primär wichtiger erschien

Ich kann es ja nur am Wochenende abends machen und da auch nur, wenn nichts anderes ist, das ist rar.

Mir ist auch immer noch nicht klar, ob es überhaupt wichtig ist, von VIRTIO auf SCSI umzustellen, also was das bringt?

Ist es so, dass ich aber vor einem Paketwechsel (also wenn ich ein Image ziehe und das dann auf ein neues netcup-Paket einspiele) besser gleich schon SCSI habe oder ist das dann egal?

frostschutz · Jun 18th 2019

Quote from franc

Mir ist auch immer noch nicht klar, ob es überhaupt wichtig ist, von VIRTIO auf SCSI umzustellen, also was das bringt?

Wenn bei dir alles funktioniert dann gibts auch keinen Grund zum wechseln.

Bei mir gabs mal richtig fiese Hänger mit virtio (cpu stuck) und seitdem stehts auf scsi... aber das ist eine Ewigkeit her.

H6G · Jun 18th 2019

https://mpolednik.github.io/20…irtio-blk-vs-virtio-scsi/

bjo · Jul 5th 2019

H6G:

Danke für den Link. Ich meine hier mal gelesen zu haben, dass durch die BLKDISCARD-Fähigkeit von virtio-scsi ein trim quasi eine "Defragmentierung" des darunterliegenden Storage durchführen würde - bzw das, was im SCP unter "Defragmentierung" verstanden wird. Ist dem so?

H6G · Jul 5th 2019

Quote from bjo

dass durch die BLKDISCARD-Fähigkeit von virtio-scsi ein trim quasi eine "Defragmentierung" des darunterliegenden Storage durchführen würde - bzw das, was im SCP unter "Defragmentierung" verstanden wird. Ist dem so?

Es wird dem darunterliegendem Storage mitgeteilt, dass der Block anderweitig beschrieben werden kann.

Mitlerweile gibt es ja zwei Defragmentierungsbegriffe bei Netcup.

bjo · Jul 5th 2019

Quote from H6G

Es wird dem darunterliegendem Storage mitgeteilt, dass der Block anderweitig beschrieben werden kann.

Mitlerweile gibt es ja zwei Defragmentierungsbegriffe bei Netcup.

Also ist der Speicherplatz nicht "fest" allokiert wie beispielsweise wenn man einer VM ein LV zuweisen würde?

Worin unterscheiden sich die beiden Defragmentierungsbegriffe?

H6G · Jul 5th 2019

Quote from bjo

Also ist der Speicherplatz nicht "fest" allokiert wie beispielsweise wenn man einer VM ein LV zuweisen würde?

Das weiß am Ende nur Netcup. Deine Snapshots zählen ja auch zu deinem Speicher dazu. Wenn du über 50% deines Speichers nutzt, können keine Snapshots mehr angelegt werden.

Ich weiß auch nicht wie Netcup die Platten nutzt um Seek-Times zu reduzieren. Die äußeren Sektoren eines Plattern sind ja schneller als die inneren. Wie auch immer man da Fairness herstellt.

Quote from bjo

Worin unterscheiden sich die beiden Defragmentierungsbegriffe?

Die normale Defragmentierung macht einen FS-Trim.

Die intensive Speicheroptimierung kopiert wohl Blöcke vom A nach B und dauert entsprechend. Performance soll dadurch auch steigern.

Das wird aber auch nur durchgeführt, wenn dein Dateisystem entsprechend fragmentiert und zerklüftet ist.

bjo · Jul 5th 2019

Danke für deine Erläuterungen!

franc · Nov 25th 2022

Quote from SCD

Besser sind die UUIDS:

# blkid

Code

/dev/sda1: UUID="12b31a3c-ec0d-4b7d-be81-dd452fc3105e" TYPE="ext4" PARTUUID="a88deea1-01"
/dev/sda2: UUID="da056ebe-49fe-412d-83e2-1436dec92676" TYPE="swap" PARTUUID="a88deea1-02"

Wird zu:

Code

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                                 <mount point>   <type>  <options>                               <dump>  <pass>
UUID=12b31a3c-ec0d-4b7d-be81-dd452fc3105e       /               ext4    usrquota,grpquota,errors=remount-ro     0       1
UUID=da056ebe-49fe-412d-83e2-1436dec92676       none            swap    sw                                      0       0

Wenn das System danach nicht startet kann man einfach wieder auf VIRTIO zurückstellen.

Display More

Ich wollte schon einen neuen Thread mit der selben Frage erstellen, da hab ich meinen alten Thread wieder gefunden.

Steht bei mir immer noch auf VIRTIO (statt SCSI). Es steht mal wieder ein do-release-upgrade an, dieses Mal auf 22.04 LTS.

Kann ich denn mal testweise im SCP auf SCSI umstellen und neu starten, oder kann ich dann nicht mehr zurück?
Also kann ich dann, wenn das System nicht mehr startet, einfach wieder auf VIRTIO zurück stellen und dann startet es wieder?

Oder das eine Einwegumstellung?

Ich hab mal in meine fstab rein geschaut:

Code

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda2 during installation
UUID=9f8a5461-c328-43bb-8b75-c43182c1433a /               ext4    discard,relatime,errors=remount-ro 0       1
# swap was on /dev/vda1 during installation
UUID=12b072a2-0d6c-4395-ba64-773226745b8f none            swap    sw              0       0

Display More

und blkid ergbit:

Code

#blkid
/dev/vda1: UUID="12b072a2-0d6c-4395-ba64-773226745b8f" TYPE="swap" PARTUUID="000bf157-01"
/dev/vda2: UUID="9f8a5461-c328-43bb-8b75-c43182c1433a" TYPE="ext4" PARTUUID="000bf157-02"

/etc/default/grub hat (ohne Kommentare):

Code

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""

aRaphael · Nov 25th 2022

Ich habe Server schon mehrmals zwischen virtio und scsi hin- und hergeschaltet. Gebootet haben die danach immer.

Das ist aber natürlich keine Garantie, sondern nur ein Erfahrungsbericht.

cltrmx · Nov 25th 2022

Quote from aRaphael

Ich habe Server schon mehrmals zwischen virtio und scsi hin- und hergeschaltet. Gebootet haben die danach immer.

Das ist aber natürlich keine Garantie, sondern nur ein Erfahrungsbericht.

Ich habe das (in der Hoffnung ebenfalls eine gesteigerte IO-Performance zu bekommen) auch schon bei verschiedenen vServern probiert. Gebootet haben diese in jedem Fall (bei mir).

franc · Nov 25th 2022

Auf der SCP > Medien Seite steht bei mir auch: "Es ist eine intensive Speicher-Optimierung notwendig. Diese kann bis zu 6 Stunden 36 Minuten andauern."

Speichernutzung: 260 GiB von 312 GiB belegt

Ist es sinnvoll diese zuerst zu machen, bevor ich mal umschalte, oder hat das miteinander nichts zu tun?

Code

#df
Dateisystem                1K-Blöcke   Benutzt Verfügbar Verw% Eingehängt auf
udev                         6124224         0   6124224    0% /dev
tmpfs                        1229620       776   1228844    1% /run
/dev/vda2                  320938096  92113616 212499324   31% /
tmpfs                        6148096         0   6148096    0% /dev/shm
tmpfs                           5120         4      5116    1% /run/lock
tmpfs                        6148096         0   6148096    0% /sys/fs/cgroup
12.34.56.78:/voln12345a1 262144000 216090176  46053824   83% /mnt/storagespace
tmpfs                        1229616         0   1229616    0% /run/user/0

aRaphael · Nov 25th 2022

Warum willst du eigentlich auf SCSI umstellen?

Mit großer Wahrscheinlichkeit wird deine Festplattenperformance dann schlechter werden.

Wenn du z.B. eines der vorkonfigurierten Images einspielst, dann wird das System automatisch den geeigneten Treiber wählen.

Für ältere Systeme wird das meist virtio sein. (Irgendwo in den Untiefen des Forums gibt es auch eine Aussage eines netcup-Mitarbeiters dazu) Das relativiert ja schon die "Empfehlung" scsi, die im SCP steht.

EDIT:

Ja, ich weiß, ich habe schon wieder nicht gegendert...

TBT · Nov 25th 2022

Es gibt mehrere Threads hier, die für VirtIO eine deutlich bessere Performance zeigen.

KB19 · Nov 25th 2022

franc Wenn es Dir um höchste Performance geht, solltest Du am Besten gar keine Snapshots verwenden. (Und das Speichermedium im SCP "optimieren" [lassen].)

Mit der Treiberauswahl hat das allerdings nichts zu tun.