ZFS- VM Disk voll

[pvenewbee]

Hallo,



ich weiß nicht genau, was da passiert ist. Vielleicht hat ja jemand eine Ahnung und kann mir vor allem für die Vermeidung in der Zukunft hilfreiche Tips geben...



Gegeben ein Ryzen mit 2TB NVMe-SSD für VMs (ZFS), irgendwann mit PVE 7.x eingerichtet (zwei Partitionen, letzte Partition 8MB). Jetzt 9.0.6.

Darauf etliche VMs und LXC (ZVOL+Datasets, einige Snapshots), ich würde sagen, netto 800GB.



Im laufenden Betrieb zeigte der PVE unter Storage/<diese SSD> ungefähr 1,4TB Auslastung an (warum?). Also dachte ich mir, es wäre gut, *rechtzeitig* auf eine größere SSD zu migrieren. So lief das ein paar Monate (inkl. Reboots und Updates).



Gestern habe ich eine 4TB SSD erhalten. Proxmoxhost heruntergefahren, SSD ausgebaut, die neue leere SSD daneben gehangen. Debian 13-VM gebootet, NVMe-Disks durchgereicht. Neuen Pool angelegt.

zpool create -f -o ashift=12 newpool /dev/disk/by-id/<ID>



Snapshot gemacht.

zfs snapshot -r oldpool@20250908



Snapshot rekursiv senden wollen:

zfs send -R oldpool@20250908 | zfs recv -F newpool



Fehlermeldung sinngemäß:

cannot hold | out of space

cannot receive stream



Blick auf den Pool - voll.



Ich weiß von Snapshots, dass sie nur das Delta von einem Punkt zum nächsten speichern. Da müssten innerhalb von 0,5s 400GB zustandegekommen sein, wenn es daran gelegen haben soll. Lange Rede, kurzer Sinn, ich konnte da nichts recovern. Weder mit Klonen der Partition auf die neue SSD und dann Anpassen der Partitionieren (ich konnte wegen keinem Speicher frei ja das Attribut autoexpand=on nicht setzen), noch mit Löschen von Dateien (auch dazu braucht man Speichern), noch Truncate von irgendwelchen Dateien im Dateisystem.



Kann sich jemand einen Reim drauf machen, was da passiert sein könnte? Vor allem - wie verhindert man, dass das wieder auftritt?



(Ich konnte mir mit einer weiteren SSD behelfen, über die ich die Storages von jeder VM auf sie gemoved habe; oldpool habe ich dann weggeworfen (und im worst case hätte ich auch noch ein Backup gehabt))

 

[news]

Zeige bitte auch mal zpool status und zpool list -v.

Nun nicht ganz, bei ersten Snapshot ist dieser dann 100%, da er ja gesendet werden soll.
Ich hätte als erstes zpool trim <zfs-pool> laufen lassen.
Danach zpool scrub <zfs-pool>

Für ein Dublikat, dass auch bootfähig sein müsste, muss man noch etwas mehr Aufwand treiben:
# https://www.thomas-krenn.com/de/wiki/Boot-Device_Replacement_-_Proxmox_ZFS_Mirror_Disk_austauschen

Danach hätte ich die neue ZFS Partition mit der bestehenden ZFS Partition zusammen gelegt:
zpool attach <zfs-pool> <old-disk-part> <new-disk-part>

Der die Partition dann vollständig angelegt ist, kann man ein Boottest über die neue NVMe machen und die alte wieder aus dem ZFS Miiror entfernen.
zpool detach <zfs-pool> <old-disk-part>

Dann noch die Booldisk säubern und am ende die neue NVMe auf ihr Maximum erweitern:

zpool set autoexpand=on <zfs-pool>
zpool online -e <zfs-pool> <new-disk-part>
zpool set autoexpand=off <zfs-pool>

Wie auch immer ist nur ein Datenträger für ZFS zu wenig, man kann nicht von allen Vorteilen profitieren.
Insbesondere ohne Backup.
Bitte auch an zfs get atime <zfs-pool> und zfs get quota <zfs-pool> denken.
Der ZFS Pool muss ein Quota erhalten.

 

[pvenewbee]

Zeige bitte auch mal zpool status und zpool list -v.

ich habe nach den Merkwürdigkeiten nur mehr an einer Kopie gearbeitet, müsste ich gucken, ob ich noch mal mit der 2TB-SSD eine VM starte.
Bei zpool status fiel mir nichts auf, zpool list habe ich nur ohne -v aufgerufen

(Update:

root@deb13ssd:~# zpool list
NAME            SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
oldpool  1.81T   469G  1.35T        -         -    41%    25%  1.00x    ONLINE  -
root@deb13ssd:~# zpool list -v
NAME                                             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
oldpool                                   1.81T   469G  1.35T        -         -    41%    25%  1.00x    ONLINE  -
  nvme-Samsung_SSD_990_PRO_2TB_S7DNffffffffff   1.82T   469G  1.35T        -         -    41%  25.3%      -    ONLINE
root@deb13ssd:~# df -Pk
Filesystem                      1024-blocks     Used Available Capacity Mounted on
udev                                3982684        0   3982684       0% /dev
tmpfs                                811828     1776    810052       1% /run
efivarfs                                256      116       136      46% /sys/firmware/efi/efivars
/dev/mapper/deb13ssd--vg-root     115071032 11364048  97815504      11% /
tmpfs                               4059136        8   4059128       1% /dev/shm
tmpfs                                  5120        8      5112       1% /run/lock
tmpfs                                  1024        0      1024       0% /run/credentials/systemd-journald.service
tmpfs                               4059140        8   4059132       1% /tmp
/dev/sda2                            965872   172316    727152      20% /boot
/dev/sda1                            997432     8984    988448       1% /boot/efi
oldpool                           128      128         0     100% /oldpool
oldpool/subvol-120-disk-0      934912   934912         0     100% /oldpool/subvol-120-disk-0
oldpool/subvol-122-disk-0      646656   646656         0     100% /oldpool/subvol-122-disk-0
tmpfs                                811824       88    811736       1% /run/user/112
tmpfs                                811824       72    811752       1% /run/user/0

root@deb13ssd:~# zpool status
  pool: oldpool
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:08:38 with 0 errors on Sat Aug  9 20:32:40 2025
config:

        NAME                                            STATE     READ WRITE CKSUM
        oldpool                                   ONLINE       0     0     0
          nvme-Samsung_SSD_990_PRO_2TB_S7DNNfffffff  ONLINE       0     0     0

errors: No known data errors

)

Nun nicht ganz, bei ersten Snapshot ist dieser dann 100%, da er ja gesendet werden soll.

verstehe ich nicht. 100% war der Pool gefüllt. Und das kann ich schon nicht einsehen, weil sich ja ziemlich sicher nichts geändert hat. Sprich, das zu sichernde Delta war vorher schon ziemlich sicher identisch. Ich kenne Snapshots eigentlich als Problem, wenn man zuviel Durchsatz hat und zuviele und zulange die Snapshots aufhebt als dieser Durchsatz erlaubt.

Ich hätte als erstes zpool trim <zfs-pool> laufen lassen.
Danach zpool scrub <zfs-pool>

hätte ich natürlich machen können, aber wenn der Speicher voll ist, ist er doch voll?
(Update:
zpool trim <pool>: ohne sichtbare Reaktion, im Journal ein Hinweis auf "die SSD ist online"
zpool scrub <pool>: out of space

Für ein Dublikat, dass auch bootfähig sein müsste, muss man noch etwas mehr Aufwand treiben:
# https://www.thomas-krenn.com/de/wiki/Boot-Device_Replacement_-_Proxmox_ZFS_Mirror_Disk_austauschen

danke für Deine Ergänzung, aber es ging doch gar nicht um ein Bootlaufwerk

Danach hätte ich die neue ZFS Partition mit der bestehenden ZFS Partition zusammen gelegt:
zpool attach <zfs-pool> <old-disk-part> <new-disk-part>

stimmt, mit send/receive habe ich es möglicherweise schwieriger gemacht als nötig. Außerdem hätte ich vermutlich ohne den Snapshot zu generieren gar kein Problem gehabt. ...Fürs nächste Mal.

Wie auch immer ist nur ein Datenträger für ZFS zu wenig, man kann nicht von allen Vorteilen profitieren.
Insbesondere ohne Backup.

ich schrieb, ich habe auf eine weitere SSD verschieben können und auch, dass ich ein Backup gehabt hätte.
Wenn Du Dich auf ein zfs-RAID beziehst - warum? Die SSDs haben genügend IOPS und ziemlich sicher innerhalb ihrer Generation eine ähnliche Laufzeit. Ich staune, wieviele Leute derzeit RAID-1 o.ä. mit identischen SSDs implementieren wollen - was soll mir das nützen, wenn die einzelnen Blockdevices zu ziemlich sicher derselben Zeit ausfallen (weil auch gleiche Transferleistung)? Bringt ja nicht einmal für Verfügbarkeit was.

zBitte auch an zfs get atime <zfs-pool> und zfs get quota <zfs-pool> denken.
Der ZFS Pool muss ein Quota erhalten.

schau ich mir an (Update: atime ist überall an (ich verwende PBS); quota nicht gesetzt); wegen quota bin ich mir nicht sicher. Sollte da nicht eher ein refreservation hin?