Dateisystem nicht mountbar

[evolver]

Hallo zusammen,

nach einer Größenänderung einer Festplatte in ESXi kann mein Linux-System die Platte nicht mehr mounten.
Ich bin mir nicht sicher, ob das ein Problem mit ESXi oder mit dem Linux ist. Deshalb seid ihr jetzt meine erste Anlaufstelle.

Leider weiß ich auch nicht, was ich so prüfen soll.

Die Platte habe ich von 15 TB auf 16 TB erweitert. Platz ist noch genug auf dem Datastore.
Danach hatte ich das Debian-System neugestartet und es hing beim Start. Der Start war sonst nie ein Problem.
Wenn ich nun die Platte aus der VM entferne, das Linux-System boote (bei der Platte handelt es sich nicht um die Haupt-Platte für das System) und anschließend die Platte wieder hinzufüge, erhalte ich im Linux auch die Meldung, dass sdb gefunden wurde.
Egal was ich dann mache, jeder Befehl hängt sich auf. Wobei das System selbst noch erreichbar ist.

Ich habe es auch mal mit einem anderen Linux-System probiert, habe dort aber die selben Probleme. Ich gehe somit davon aus, dass es entweder ein Problem mit dem Dateisystem ist oder irgendwas am ESXi nicht stimmt.

Hier der Log des Servers:

Jun 22 23:05:08 nas kernel: [ 261.212975] vmw_pvscsi: msg type: 0x0 - MSG RING: 1/0 (5)
Jun 22 23:05:08 nas kernel: [ 261.212979] vmw_pvscsi: msg: device added at scsi0:1:0
Jun 22 23:05:08 nas kernel: [ 261.213110] scsi 2:0:1:0: Direct-Access VMware Virtual disk 2.0 PQ: 0 ANSI: 6
Jun 22 23:05:08 nas kernel: [ 261.213357] sd 2:0:1:0: [sdb] 34359738368 512-byte logical blocks: (17.5 TB/16.0 TiB)
Jun 22 23:05:08 nas kernel: [ 261.213415] sd 2:0:1:0: [sdb] Write Protect is off
Jun 22 23:05:08 nas kernel: [ 261.213428] sd 2:0:1:0: [sdb] Cache data unavailable
Jun 22 23:05:08 nas kernel: [ 261.214165] sd 2:0:1:0: Attached scsi generic sg2 type 0
Jun 22 23:05:08 nas kernel: [ 261.234211] sdb: sdb1
Jun 22 23:10:47 nas kernel: [ 600.046628] debugfs D 00000000 0 970 950 0x00000000
Jun 22 23:10:47 nas kernel: [ 600.046636] de773d38 00000086 00000000 00000000 dfff5048 c1717000 c1717000 a8cab478
Jun 22 23:10:47 nas kernel: [ 600.046638] 00000058 dfff5000 db66f560 c1717000 a8c6e29d 00000058 00000001 db66f560
Jun 22 23:10:47 nas kernel: [ 600.046641] c165f6c0 dfff5974 00000001 c165f6c0 c123a1c4 dc2dfc00 e09bc2e0 de54c800
Jun 22 23:10:47 nas kernel: [ 600.046643] Call Trace:
Jun 22 23:10:47 nas kernel: [ 600.046661] [<c123a1c4>] ? get_disk+0x24/0x50
Jun 22 23:10:47 nas kernel: [ 600.046704] [<c123a1d0>] ? get_disk+0x30/0x50
Jun 22 23:10:47 nas kernel: [ 600.046714] [<c147fe83>] ? schedule_preempt_disabled+0x23/0x60
Jun 22 23:10:47 nas kernel: [ 600.046716] [<c1481479>] ? __mutex_lock_slowpath+0xb9/0x199
Jun 22 23:10:47 nas kernel: [ 600.046718] [<c1480a8c>] ? mutex_lock+0x1c/0x28
Jun 22 23:10:47 nas kernel: [ 600.046724] [<c119ecf8>] ? __blkdev_get+0x58/0x3e0
Jun 22 23:10:47 nas kernel: [ 600.046725] [<c119d780>] ? bdev_test+0x20/0x20
Jun 22 23:10:47 nas kernel: [ 600.046728] [<c119ee72>] ? __blkdev_get+0x1d2/0x3e0
Jun 22 23:10:47 nas kernel: [ 600.046730] [<c119f1ec>] ? blkdev_get+0x16c/0x290
Jun 22 23:10:47 nas kernel: [ 600.046731] [<c119d780>] ? bdev_test+0x20/0x20
Jun 22 23:10:47 nas kernel: [ 600.046733] [<c119e628>] ? bd_acquire+0x78/0xb0
Jun 22 23:10:47 nas kernel: [ 600.046739] [<c116cc78>] ? do_dentry_open+0x1e8/0x2c0
Jun 22 23:10:47 nas kernel: [ 600.046740] [<c119f350>] ? blkdev_get_by_dev+0x40/0x40
Jun 22 23:10:47 nas kernel: [ 600.046742] [<c116cd7b>] ? finish_open+0x2b/0x40
Jun 22 23:10:47 nas kernel: [ 600.046746] [<c117bc86>] ? do_last+0x936/0xf30
Jun 22 23:10:47 nas kernel: [ 600.046747] [<c117c330>] ? path_openat+0xb0/0x550
Jun 22 23:10:47 nas kernel: [ 600.046749] [<c117cf81>] ? do_filp_open+0x31/0x80
Jun 22 23:10:47 nas kernel: [ 600.046751] [<c116e05a>] ? do_sys_open+0x10a/0x200
Jun 22 23:10:47 nas kernel: [ 600.046759] [<c10199b7>] ? init_fpu+0x77/0xa0
Jun 22 23:10:47 nas kernel: [ 600.046762] [<c1010720>] ? do_int3+0xd0/0xd0
Jun 22 23:10:47 nas kernel: [ 600.046764] [<c1019845>] ? fpu_finit+0x55/0x70
Jun 22 23:10:47 nas kernel: [ 600.046766] [<c1010000>] ? do_signal+0x8f0/0xa20
Jun 22 23:10:47 nas kernel: [ 600.046767] [<c116e172>] ? SyS_open+0x22/0x30
Jun 22 23:10:47 nas kernel: [ 600.046769] [<c1482a9f>] ? sysenter_do_call+0x12/0x12

Die CPU-Last ist dann bei 100%. Die Festplatte ist allerdings nicht ausgelastet.

Tut mir leid, dass ich nicht mehr Infos geben kann, aber momentan stehe ich etwas hilflos vor dem Ganzen und habe die Befürchtung, dass meine Daten weg sind, wenn ich was Falsches mache.

Vielen Dank für eure Hilfe!

[irix]

Hmm.... war da nicht was mit einem Problem wenn der Datastore auf/ueber 16TB vergroessert wurde?

Edit: https://kb.vmware.com/kb/2079071


Gruss
Joerg

[~thc]

Da man bei einem modernen Debian von ausreichendem Support für die Disks und die GPT-Partition(stabelle) ausgehen kann, liegen Limits nur noch für das Dateisystem vor. Da du keine Infos dazu gepostet hast, vermute ich ein ReiserFS oder Ext4-Volume, dass jetzt einige Blöcke größer ist, als das technische Maximum von 16 TB.

[evolver]

Korrekt, das Dateisystem ist Ext4.
Der Datastore war vorher bereits so groß, da habe ich nichts verändert.
Das Dateisystem habe ich ja auch noch nicht vergrößert. Momentan ist ja nur die Platte für das Linux-System 16 TB groß. Die Partition und das Dateisystem wollte ich nach dem Neustart vergrößern, der dann ja nicht funktioniert hat.

[~thc]

Dann kommentiere doch mal die Partition "sdb1" aus "/etc/fstab" aus und teste, ob die VM hochfährt.

[evolver]

Was seltsam ist: Gestern hatte ich als SCSI-Controller noch den "VMware Paravirtual SCSI" eingestellt. Da hing der Boot.
Jetzt habe ich das abgeändert auf "LSI Logic SAS". Dann kommt beim Starten zwar auch ein Fehler, aber er bootet dann zumindest in den Emergency-Mode.
Habe dann den /dev/sdb1-Eintrag in fstab auskommentiert und neugestartet. Jetzt bootet er komplett durch.

Danach habe ich versucht, manuell mit "mount -t ext4 /dev/sdb1 /mnt/nas" zu mounten, was dann aber wieder hing:

In /var/log/messages steht dann wieder das hier:
Jun 23 11:44:20 carida kernel: [ 363.498721] systemd-udevd D 0 311 261 0x00000104
Jun 23 11:44:20 carida kernel: [ 363.498722] df471e00 db7bc080 df410e00 dc0abdd8 ce5a988e 00000000 e0baf02e ce78d7bc
Jun 23 11:44:20 carida kernel: [ 363.498724] 0078af98 db7bae38 ce767680 db7bc080 dfff4a40 db7baa40 00000000 db7baa40
Jun 23 11:44:20 carida kernel: [ 363.498726] ffffffff ffffffff dc0abde4 ce5a9dbe 00000000 dc0abe2c ce086a7b 00000000
Jun 23 11:44:20 carida kernel: [ 363.498728] Call Trace:
Jun 23 11:44:20 carida kernel: [ 363.498730] [<ce5a988e>] ? __schedule+0x25e/0x760
Jun 23 11:44:20 carida kernel: [ 363.498738] [<e0baf02e>] ? acpi_battery_init_async+0x14/0x14 [battery]
Jun 23 11:44:20 carida kernel: [ 363.498740] [<ce5a9dbe>] ? schedule+0x2e/0x80
Jun 23 11:44:20 carida kernel: [ 363.498742] [<ce086a7b>] ? async_synchronize_cookie_domain+0xeb/0x170
Jun 23 11:44:20 carida kernel: [ 363.498747] [<ce0851f2>] ? __blocking_notifier_call_chain+0x42/0x60
Jun 23 11:44:20 carida kernel: [ 363.498748] [<ce0a8310>] ? prepare_to_wait_event+0xd0/0xd0
Jun 23 11:44:20 carida kernel: [ 363.498750] [<ce166395>] ? do_init_module+0xab/0x1be
Jun 23 11:44:20 carida kernel: [ 363.498751] [<ce0f28df>] ? load_module+0x203f/0x2670
Jun 23 11:44:20 carida kernel: [ 363.498754] [<ce0f3130>] ? SyS_finit_module+0xb0/0x100
Jun 23 11:44:20 carida kernel: [ 363.498755] [<ce00320f>] ? syscall_trace_enter+0x16f/0x260
Jun 23 11:44:20 carida kernel: [ 363.498756] [<ce0036fa>] ? do_fast_syscall_32+0x8a/0x150
Jun 23 11:44:20 carida kernel: [ 363.498757] [<ce5ae0ca>] ? sysenter_past_esp+0x47/0x75

Da ich die Partition noch nicht vergrößert habe, könnte ich doch die Platte wieder von 16 TB auf 15 TB verkleinern und schauen, ob das Mounten dann wieder funktioniert, oder? Leider verbietet das VMware-WebUI die Änderung. Kann ich das irgendwie anders durchführen?

[Dayworker]

Welche Version von "e2fsprogs" hast du installiert?
Wurde die Riesenpartition noch mit der 32bit-Version angelegt? Ohne das 64bit-Bit ist EXT4 auf 16TB beschränkt.

JA, VMware sieht nur eine Vergrösserung über seine GUI vor. Der Rückweg geht entweder über den bekanntermaßen lahmen VMware-Converter oder für sehr erfahrene Anwender auch per dd-Magie.

Hast du eigentlich ein Backup der Riesenpartition?
Falls nicht, darfst du dich auf einen vollständigen Datenverlust einstellen. Gut möglich, daß nach den 16TB der Datenträgeranfangsbereich überschrieben wird. Der ESXi kann je nach VMFS-Version meines Wissens bis zu 64TB grosse Partitionen anlegen und VMDKs dürfen bis zu 62TB groß sein.

[evolver]

Es handelt sich um ein Debian 9-System. Somit sollte e2fsprogs >= 1.42 (scheinbar 1.43) installiert sein.

Was mich wundert: Ich kann keinerlei Dateiprüfung durchführen. Immer wenn ich etwas versuche, hängt sich der Prozess auf und der kworker-Prozess geht auf 100%. Also scheinbar irgendwas im Kernel, was die komplette CPU beansprucht.

Das einzige, was ich jetzt ausführen konnte, war lsblk. Da habe ich sdb1 und sda1 verglichen und sdb1 scheint viele Daten zu fehlen. Jetzt weiß ich natürlich nicht, ob die Daten tatsächlich nicht mehr da sind oder ob diese nur nicht eingelesen wurden.

Wie könnte ich denn weiter vorgehen und das Problem ggf. weiter einschränken?

[~thc]

Habe dann den /dev/sdb1-Eintrag in fstab auskommentiert und neugestartet. Jetzt bootet er komplett durch.

Das deutet - mit allen anderen Fehlern - darauf hin, dass das Dateisystem komplett im Eimer ist, so dass udevd und kernel völlig austicken.

Da weder Partition noch Dateisystem vergrößert wurden: Hast du die virtuelle Festplatte vergrößert, während die VM lief?

Ist der Datastore auf einem NAS? iSCSI oder NFS? Wurde dieser vor Kurzem vergrößert?

[evolver]

Jetzt wo du es sagst: Ja, ich glaube, ich habe die Platte vergrößert, als die VM noch angeschaltet war. Mist.

Was passiert dann? Schreibt Linux dann in den Bereich der GPT oder wie muss ich mir das vorstellen?
Gibt‘s Tools womit ich die Partitionstabelle wiederherstellen kann? Oder womit ich Dateien auf der Platte suchen kann? (Testspiel kann das doch, oder?)
Müsste nicht am Ende des alten Bereichs noch ein GPT-Backup sein, sofern das nicht überschrieben wurde?
Leider kann ich halt momentan keinerlei Tool über das Laufwerk laufen lassen, da der Kernel keinen Zugriff zulässt.

Am besten ein komplettes Backup der VMDK anlegen und dann versuchen, die GPT neu zu schreiben?

Datastore liegt auf einem lokalen RAID und wurde kürzlich nicht vergrößert.

[~thc]

Erst einmal: Prinzipiell geht das Vergrößern online gefahrlos - ich habe das bei Linux- und WIndows-VMDK schon oft getan.

Andererseits hat der Anfang deiner Partition sdb1 (oder der vDisk) offensichtlich gelitten - daher meine Vermutung, dass da vorher etwas war.

Bitte methodisch vorgehen:

- Ist die GPT-Partitionstabelle der vDisk intakt?
- Enthalten die ersten Sektoren der vDisk die richtigen Daten oder kann man sehen, dass da ein wild gewordener Prozess etwas reingeschrieben hat?

[evolver]

- Ist die GPT-Partitionstabelle der vDisk intakt?
- Enthalten die ersten Sektoren der vDisk die richtigen Daten oder kann man sehen, dass da ein wild gewordener Prozess etwas reingeschrieben hat?

Habe auf dem Host jetzt per hexdump die ersten Bytes der Flat-VMDK-Files ausgeben lassen.
Die defekte VMDK hat sehr große 0x00-Bereiche. Zum Vergleich habe ich dann von zwei anderen VMs, die auch ext4-formatiert sein müssten, die VMDKs ausgeben lassen. Ich hätte jetzt erwartet, dass zumindest die Anfänge der beiden funktionierenden VMs gleich sind, was aber nicht so ist.

Hier sind die Daten. Bei der fehlerhaften VMDK-Datei habe ich die ersten 1 MiB ausgeben lassen. Nach dem Dump kommen dann auch ein paar Daten ungleich 0x00.
Bei den anderen nur 5 KiB.

Außerdem habe ich per vmkfstools -x check die Dateien prüfen lassen:

[root@esxi:/vmfs/volumes/5a46d6af-e0576b66-a407-50e54920a091/NAS_Data] vmkfstools -x check ./NAS_1.vmdk
Disk is error free
[root@esxi:/vmfs/volumes/5a46d6af-e0576b66-a407-50e54920a091/NAS_Data] vmkfstools -x check ./NAS_1-flat.vmdk
DiskLib_Check() failed for source disk './NAS_1-flat.vmdk': The file specified is not a virtual disk (15).

Ich denke, ich werde mir nächste Woche mal ein paar neue Platten besorgen und die VMDK im aktuellen Zustand mal sichern.

Vielen Dank für eure Hilfe!

[Dayworker]

Eine vDISK auf dem ESXi besteht immer auch der kleinen Beschreibung-VMDK und der Flat-Datei. Wenn dir also vmksf -x check ./NAS_1.vmdk ein "Disk is error free" ausgibt, ist die VMDK erstmal aus VMware-Sicht in Ordnung. Probierst du dasselbe mit einer Flat-Datei, bekommst du immer die Meldung "The file specified is not a virtual disk."

Das sieht nicht gut aus. Mein Rat wäre jetzt, melde dich bei unserem VMDK-Guru Ulli aka "continuum". Kontaktdaten stehen bei ihm in der Signatur. Vielleicht kennt er das Problem bereits und weiß eine Lösung. Allerdings dürfte es bei der VMDK-Grösse eh Schwierigkeiten mit dem Backup geben. Die größten mir bekannten Platten sind mit 14TB als Einzellaufwerk erhältlich und alles darüber wird folglich zusammengeschaltet. Bei laut Plattenhersteller üblichen 1TB gleich 1000GB und geschätzten 100MB/s, am Anfang der Platte sicherlich deutlich schneller und dann zur Plattenmitte genauso deutlich abnehmend, dauert das Backup rein rechnerisch gute 38 Stunden. Bei solchen Zeiten sollte man sich so grosse Datenträger nochmal reiflich überlegen, denn vor Mittwoch wirst du an der VMDK wohl nichts machen können...

[~thc]

Die "korrekte" VM hat eine "alte" MS-DOS-Partitionstabelle und die "fehlerhafte" einen GPT-Protection-Sektor mit darauf folgender GPT-Partitionstabelle. ("EFI PART") Das ist also erst mal kein Problem.

- Die GPT-Tabelle beginnt bei 0x200. Der Eintrag für sdb1 steht bei 0x400 bis 0x430.
- Bei einem meiner Server beginnt ext4-Partition auch bei 0x100400.
- Daraus lässt sich also nichts "Schlimmes" ablesen.

Teste doch mal mit einem GPT-Tool (gdisk, parted), ob die Partitionen und die Diskgröße noch korrekt erkannt werden.

[evolver]

Ja, das war wahrscheinlich eine schlechte Idee, alles auf eine VMDK zu packen und dann über die NAS nur die Verzeichnisse freizugeben. Hat natürlich den Vorteil, dass der Platz zwischen den einzelnen Shares gut verteilt wird. Ist aber halt später schwer zu handhaben.

Wie würde ich sowas denn "richtig" machen Das größte Share auf der NAS ist so ca. 7-8 TB groß. Das wäre dann meine größte VMDK. Oder würdet ihr die VMDKs noch kleiner machen und die im NAS wieder irgendwie zusammenbauen? Das würde doch nur einen weiteren Punkt schaffen, der kaputt gehen könnte...?

Mein Gefühl sagt mir, dass die Datenplatte an sich in Ordnung ist und dass das Problem irgendwo zwischen ESXi/SCSI-Treiber und dem Linux hängt.
Da die kleine VMDK-Datei in Ordnung ist, wird es daran wohl nicht liegen?

Was halt seltsam ist, ist, dass ich mit keinerlei Tools auf die gemappte Platte zugreifen kann. Habe es mit zwei Debian 9-VMs versucht und beide zeigen 100% CPU Last bei Zugriff auf die Platte. Kann ich das irgendwie debuggen?
Ich habe hier noch eine "System Rescue Disk" mit ein paar Disk-Tools. Mit der werde ich gleich noch etwas testen. Alles aber nur read-only.

Voraussichtlich am Mittwoch bekomme ich zwei 8 TB-Platten. Diese werde ich zusammen mit einer 3 TB-Platte, die ich noch hier habe zu einem JBOD verbinden und darauf die VMDK klonen in der Hoffnung, dass dann wieder alles gut ist.

Was könnte ich bis dahin denn vielleicht noch testen? Gibt's Software für Windows, die ext4 lesen kann? Oder mal eine andere Linux-Distri probieren?

Edit, 21:19h: Mit der System Rescure Disk lässt sich die Platte problemlos (read-only) mounten und darauf zugreifen.
Ich kopiere jetzt noch die Dateien, die in dem letzten Backup vor zwei Monaten noch nicht drin waren. Danach werde ich mir das Debian-System mal genauer anschauen. Das Problem scheint nicht im ESXi, sondern im Debian zu liegen. Warum zwei VMs unabhängig voneinander das gleiche Problem zeigen, ist mir aber noch nicht klar. Klonen der VMDK kann aber vermutlich trotzdem nicht schaden, um auf der sicheren Seite zu sein und dann das NAS mit mehreren VMDKs neu aufzusetzen.

[Dayworker]

Warum kommst du denn erst jetzt mit dem NAS ums Eck
Laß das NAS sich in einem Raid 10 um deine Platten kümmern und reich den Plattenplatz per NFS an den ESXi weiter. Wird ja hoffentlich kein Schmalspur-NAS mit nur 2 Bays sein. Selbst bei 8TB Platten dauert extern ansonsten jede Sicherung bei 100MB/s gute 22 Stunden und vernünftig bzw zeitnah gesichert bekommt man sowas im Grunde auch nur noch auf ein weiteres Plattenarray oder das jetzige NAS hat noch mindestens 2 weitere Bays frei. Mit 10GE wird dein NAS vermutlich nicht ausgestattet sein, hoffentlich kann das NAS die ersten beiden Bays auf frei Bays replizieren. Das sollte deutlich zügiger ablaufen, als wenn du die Daten erst vom NAS auf einen anderen Rechner kopieren mußt. Alternativ hast du ein zweites NAS vom selben Hersteller als Backup dastehen und kannst dann zumindest dessen beschleunigte NAS-2-NAS-Replikation nutzen.

Ich halte von NAS sehr wenig und würde sie persönlich immer nur als Backup-Medium einsetzen. Jedes NAS ist auf hohe sequentielle Datenübertragungen optimiert und die treten im virtualisierten Betrieb einfach nur selten auf. Da kommt es eher darauf an, daß man bei Random-IO im 4KB-Raster möglichst flink an die Daten kommt und das ist mit den Schmalspur-CPUs sowie geringem Speicherausbau üblicher SOHO-NAS nicht realisierbar.
Wenn man sich damit jedoch mit arrangieren kann, laufen NAS ohne irgendwelchen App-Blödsinn ausgesprochen stabil. Jedwedes Raid bedingt jedoch immer zumindest eine USV bzw einen Raid-Controller mit BBU/BBM, der bei Stromausfall zumindest das Raid noch konsistent hält. Beim Rebuild fallen aufgrund der stärkeren Belastung gerne mal zumindest 1 Datenträger aus. Nach einem Raid5/6-Rebuild verweigert VMware gerne mal die Mitarbeit aufgrund irgendwelcher Bitfehler und da VMware weiterhin keine öffentlich verfügbare Reparaturmethode für sein VMFS programmiert hat, bedeutet sowas automatisch DS einreißen, DS neu aufsetzen und Backup einspielen. Daher auch meine platzverschwenderischere Empfehlung für ein Raid10.


Debian ist nicht gerade bekannt dafür, die neuesten Versionen mitzuliefern. In der Vergangenheit war es mit EXT4 auch so, daß man zwar Platten mit mehr als 16TB anlegen konnte, aber das Vergrössern/Verkleinern scheiterte. Bedingungen, um bei EXT4 überhaupt über die 16TB-Grenze zu kommen, sind neben einem gesetzten 64bit-Bit, was eine "e2fsprogs Version 1.43" bedingt, auch einen Kernel ab 4.4.x aufwärts einzusetzen. Erst damit wird der komplette EXT4-Adressraum nutzbar. Beispielsweise beim Release von Ubuntu 16.04 wurde noch die "e2fsprogs Version 1.42" vom August 2014 mitgeliefert und vom Ubuntu-Team erst im Mai 2017 auf die benötigte Version 1.43 gebracht. Wie das bei Debian 9 aussieht, entzieht sich meiner Kenntnis.

[add]
Bei 16TB würde ich sowas nur noch einem Dateisystem anvertrauen, was mir persönlich am sichersten erscheint und vor allem von Hause auf die Verarbeitung deutlich grössere Datenmengen ausgerichtet wurde. Persönlich bin ich da wie an meiner Signatur erseichtlich komplett bei ZFS gelandet und setze auf die Nappit-Appliance.

[evolver]

Vielleicht habe ich jetzt auch für Verwirrung wegen "NAS" gesorgt.
Das Setup ist: 5x5 TB im RAID5 an einem MegaRAID-Controller ohne BBU (dafür ist das ganze System aber an einer USV).
Darauf habe ich gem. Empfehlung hier im Forum eine 20 GB Platte für ESXi + Swap eingerichtet. Der Rest ist für die VMs und die Daten (datastore1).
Eine der VMs ist ein Debian9-System ("NAS"), dass eine große VMDK (15 TB) über verschiedene Windows-Shares zur Verfügung stellt.

Aber ich bin natürlich bei Dir: Wenn ich die Aufteilung 20 GB für ESXi, 5 TB für VMs und 15 TB für die "NAS-Daten" gemacht hätte und die Datenplatte direkt an die VM durchgereicht hätte, hätte ich jetzt vermutlich nicht die Probleme.

[Dayworker]

Ohne BBU ist immer schlecht, weil dann ohne weiteren manuellen Eingriff immer der WB-Cache abgeschaltet ist und der ESXi mangels eigenem Dateisystem-Cache sich nur auf die Controller-Performance stützen kann.

Wenn man eh Platten im Raid hat, ist die Empfehlung weiterhin für den ESXi einen kleinen Bereich abzuteilen und den Rest dem ESXi als weiteren DS zur Verfügung zu stellen. Eine Datenplatte muß man auch nicht mehr direkt an eine VM durchreichen, weil der ESXi seit längerem bis zu 64TByte als DS direkt verwalten und darauf auch VMDKs bis zu 62TByte Grösse anlegen kann. Vorteil dessen ist, daß Snapshots weiterhin uneingeschränkt möglich sind. Bei durchgereichten Platten ist das ja nur in einem bestimmten Fall möglich.
Mir gehts eher darum, daß, bis auf die Areca-Controller, es fast immer Einschränkungen hinsichtlich des Gesundheitszustands von Controller und vor allem der daran angeschlossenen Datenträger kommt oder daß das nur über eine "Helfer-VM" mit bestimmten Controller-Versionen möglich ist. Der ESXi bekommt zwar direkt mit, wenn der Controller fehlt, aber das aus mehreren Raidmitgliedern bestehende VD wird nur als eine Einheit sichtbar. Mehr als Degraded habe ich da selten gesehen, aber gerade im Ausfallmoment wäre es schon interessant zu wissen, welche Platte denn nun genau ausgefallen ist und das auch ohne den Server zu rebooten. Bei Servern sind ja gerne Hotswap-Backplanes verbaut und die Backplanes zeigen meistens auch den Ausfall an, aber trotzdem würde ich sowas schon gerne vorher entweder am ESXi oder notfalls auch in der "Helfer-VM" sehen wollen. Für eine grobe Übersicht würde es meistens ja bereits ausreichen, wenn man wenigstens die SMART-Werte abfragen/einsehen könnte. Notfalls kann man dann immer noch den Server rebooten und mit einer Hersteller-CD/DVD/BR nach dem rechten sehen.
Da mir Areca einfach viel zu teuer war und ist und ich nur den Dell-Einstiegscontroller H200 habe (ist mangels Write-Cache immer lahm, ein OS-Dateisystemcache hilft auch nur bedingt), fiel meine Entscheidung auf die Nappit-Appliance und damit fahre ich bisher sehr gut. Irgendwo war ich vorher über ZFS gestolpert und habe das mal nur so zum "Spaß" halbherzig unter Linux aufgesetzt. Das war damals aber noch Murks, weil ZoL noch weit entfernt von einer für mich verständlichen, weil nutzbaren Form war und jedes Kernel-Update umfangreiche Nacharbeiten erforderte. Mit einem vollwertigen Raid-Controller plus BBU in der Hinterhand hätte ich mich vielleicht überhaupt nicht für die Appliance entschieden und wie du dieselbe Aufteilung für ESXi und VMs gewählt. Mein ESXi startet vom Stick und von einer kleine 2.5er HDD startet als erstes die Appliance, die dann wiederum über den per PCI-Passthru durchgereichten HBA alle Platten verwaltet und dem ESXi per NFS diesen Speicherplatz anbietet.