[gelöst] Problem mit ZFS - zpool.cache

[Wintendo]

Hallo,

ich habe ein merkwürdiges Problem hier und wäre für Hinweise / Lösungen dankbar.

Ausgangssituation:

Neue Proxmox-Installation auf einem DELL R340 unter Verwendung der ISO "proxmox-ve_7.3-1". Serversystem normal konfiguriert und firmwaremäßig up2date.

Installiert wurde von der ISO über die Setup-Oberfläche mittel iDRAC-Konsolenumleitung auf einen ZFS-Mirror (Raid-1). Hierbei alles bei den Voreinstellungen belassen - bis auf die Festplattenauswahl natürlich. Hier wurden alle aufgelisteten Disks abgewählt und dann nur /dev/sda und /dev/sdb für den Mirror ausgewählt. Danach Installationsvorgang problemlos durchlaufen.

Der ZFS-Mirror für root liegt also auf zwei M.2 SATA-SSDs die sich auf einem internen eingebauten BOSS-Controller befinden. Die werden einfach nur an den Host durchgereicht - kein herstellerspezifischer (Fake-) RAID-Modus eingestellt (da ginge wohl auch eine Art Spiegelung). Rest der Platten sind SAS HDD und SSD an einem DELL PERC H310 (original HBA kein HW-Raid). Die Installations-SSDs bekommen nach dem ersten Rebbot neue Bezeichner (sdh undsdi)



Folgendes Verhalten:

Nach der Installation und dem ersten Reboot gibt es offenbar kein /etc/zfs/zpool.cache. Der Import von rpool erfolgt somit über zfs-import-scan.service. Dieser wirft eine Fehlermeldung (hab ich leider nicht rauskopiert), dahingehend, dass der Pool von einem fremden System benutzt wird und zeigt dabei auch eine "hostid" an (immer dieselbe übrigens bei jedem Installationsversuch) die sich von der tatsächlichen hostid auf dem gebooteten System unterscheidet.



Aber rpool wird trotz Fehlermeldung irgendwie trotzdem (ohne manuellen Eingriff) gemountet und das System kommt hoch.

Dieses Verhalten bleibt auch reproduzierbar so, solange keine weiteren ZFS-Pools erstellt werden.

Nun wird ein erster ZFS-Pool für die Daten erstellt. Dadurch entsteht automatisch die Datei /etc/zfs/zpool.cache. Nach einem reboot übernimmt dann erwartungsgemäß zfs-import-cache.service. Warum auch immer ist dann zusätzlich zum neu erstellten Pool auch rpool in diesem Cache enthalten (mit strings auf die zpool.cache geprüft).

Ergebnis: die Fehlermeldung von zfs-import-scan.service tritt nicht mehr auf, da der Service (erwartungsgemäß) nicht gestartet wird:

systemctl status zfs-import-scan.service ● zfs-import-scan.service - Import ZFS pools by device scanning Loaded: loaded (/lib/systemd/system/zfs-import-scan.service; enabled; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Sun 2023-02-19 08:24:08 CET; 26min ago └─ ConditionFileNotEmpty=!/etc/zfs/zpool.cache was not met Docs: man:zpool(8)

Allerdings kommt jetzt für alle im Cache registierten Pools beim reboot eine Fehlermeldung (oben Einstellungen im Cachefile - unten Meldungen beim reboot) - hier für T2-datastore-00

# zpool get cachefile NAME PROPERTY VALUE SOURCE T1-datastore-00 cachefile none local T2-datastore-00 cachefile - default rpool cachefile - default *** systemd[1]: Starting Import ZFS pools by cache file... systemd[1]: Condition check resulted in Import ZFS pools by device scanning being skipped. systemd[1]: Starting Import ZFS pool T1\x2ddatastore\x2d00... systemd[1]: Starting Import ZFS pool T2\x2ddatastore\x2d00... zpool[1263]: cannot import 'T2-datastore-00': no such pool available systemd[1]: zfs-import@T2\x2ddatastore\x2d00.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: zfs-import@T2\x2ddatastore\x2d00.service: Failed with result 'exit-code'. systemd[1]: Failed to start Import ZFS pool T2\x2ddatastore\x2d00. systemd[1]: Finished Import ZFS pools by cache file. kernel: zd16: p1 p2 p3 systemd[1]: Finished Import ZFS pool T1\x2ddatastore\x2d00. systemd[1]: Reached target ZFS pool import target.

Schaltet man für alle Pools (außer rpool) den Eintrag im Cache-File aus, dann läuft alles ohne Fehlermeldung (das ist merkwürdig, weil "rpool" hier noch im Cache-File eingetragen ist aber "rpool" spielt hier wohl irgendeine besondere Rolle....):
# zpool get cachefile NAME PROPERTY VALUE SOURCE T1-datastore-00 cachefile none local T2-datastore-00 cachefile none local rpool cachefile - default **** systemd[1]: Starting Import ZFS pools by cache file... systemd[1]: Condition check resulted in Import ZFS pools by device scanning being skipped. systemd[1]: Starting Import ZFS pool T1\x2ddatastore\x2d00... systemd[1]: Starting Import ZFS pool T2\x2ddatastore\x2d00... systemd[1]: Finished Helper to synchronize boot up for ifupdown. zpool[1254]: no pools available to import systemd[1]: Finished Import ZFS pools by cache file. systemd[1]: Finished Import ZFS pool T2\x2ddatastore\x2d00. kernel: zd16: p1 p2 p3 systemd[1]: Finished Import ZFS pool T1\x2ddatastore\x2d00. systemd[1]: Reached target ZFS pool import target.

Ein / Ausschalten erfolgt jeweils mit:
zpool set cachefile=/etc/zfs/zpool.cache T2-datastore-00 bzw. zpool set cachefile=none T2-datastore-00

Man kann auch alle Pools aus dem Cache-File entfernen und dieses dann löschen. Dann übernimmt wieder zfs-import-scan.service und es kommt für rpool die Fehleldung wegen Mismatch der Host-ID.

Es werden in jeder der geschilderten Kontellationen alle Pools importiert und auch gemountet (über welchen mechanismus auch immer).

Allerdings ist mir so ein Verhalten nicht geheur und mit sowas möchte ich nicht in Produktion gehen.

Vielleicht hat ja jemand eine Idee was da passiert und wie man das vielleicht in Ordnung bringen kann.

Vielen Dank schon mal im Voraus.

 

[Wintendo]

Habe die Ursache selbst herausgefunden. Hier die Auflösung für eventuell interessierte:

Ursache war, dass die beiden gezeigten Datenpools mit der PROXMOX-GUI angelegt wurden. Dabei werden für jeden Pool anscheinend stillschweigend Services im System eingerichtet welche dafür sorgen, dass die Pools auf jeden Fall und ohne Berücksichtigung der Datei zpool.cache importiert werden.

In meinem Fall hat folgendes Kommando den Sachverhalt ans Licht gebracht. Der Service mit dem Status "failed" war immer genau der, welcher in der Datei zpool.cache aktiviert war.

# systemctl | grep zfs zfs-import-cache.service loaded active exited Import ZFS pools by cache file zfs-import@T1\x2ddatastore\x2d00.service loaded active exited Import ZFS pool T1\x2ddatastore\x2d00 ● zfs-import@T2\x2ddatastore\x2d00.service loaded failed failed Import ZFS pool T2\x2ddatastore\x2d00 zfs-mount.service loaded active exited Mount ZFS filesystems zfs-share.service loaded active exited ZFS file system shares zfs-volume-wait.service loaded active exited Wait for ZFS Volume (zvol) links in /dev zfs-zed.service loaded active running ZFS Event Daemon (zed) system-zfs\x2dimport.slice loaded active active system-zfs\x2dimport.slice zfs-import.target loaded active active ZFS pool import target zfs-volumes.target loaded active active ZFS volumes are ready zfs.target loaded active active ZFS startup target

Auf jeden Fall hat derService zum Import des dedizierten Pools diesen erfolgreich (zuerst) importiert, so dass er nicht mehr für den Import über den Service des Cache-Mechanismus verfügbar war. Da passte auch die Fehlermeldung. In der Cache-Datei deaktivierte Pool wurden weiterhin vom dedizierten Service importiert und da aus dem Cache auskonfiguriert dann ohne Fehlermeldung.

Habe früher immer die Pools direkt auf per cli mit zfs eingerichtet und da gab es solch einen Mechanismus nicht. Man darf halt nicht bequem werden und anfangen Dinge zusammenzucklicken Ist auf jeden Fall verwirrend das Verhalten. Nicht getestet habe ich, ob bei der Kombi "pool über cli erstellen und Storage im Bereich Enterprise über die GUI hinzufügen" auch diese Pool-spezifischen Import-Services entstehen.

Services wurden jedenfalls deaktiviert und alles wie gewohnt über den Cache-Mechanismus geregelt.

Was dabei noch aufgefallen ist:

udevadm[844]: systemd-udev-settle.service is deprecated. Please fix zfs-import-cache.service, zfs-import-scan.service not to pull it in.

VG

 

[TosH45]

Danke,

hatte das gleiche Problem, 24h Analyse/Google-Suche investiert und nichts gefunden - Erst Dein Post hat mein Problem gelöst.

 

[Falk R.]

zum Threadersteller:
wenn du die BOSS m.2 mit ZFS nutzt, schreibst du die extrem schnell kaputt.
Die sind nicht für ZFS geeignet.
Die sind gedacht für das eingebaute Raid1 mit einem einfachen Filesystem für eine OS Partition.
Sogar eine installierte SQL DB stresst die Dinger schon.

 

[RolandK]

hier gibt es ein bugzilla ticket dazu. https://bugzilla.proxmox.com/show_bug.cgi?id=4835

aktuell leider geschlossen "works for me". wenn es keine gegensprache oder reaktion gibt werd ich das die tage versuchen wieder öffnen. oder vielleicht öffnet jemand anderes es nochmal.

@TosH45 @Wintendo