Snapshot größer als VM Disk

[kunstlust]

Ich habe eine 2TB Disk angelegt, diese belegt nach einem Snapshot gleich 1.5 TB mehr, obwohl sich nicht geändert hat.
Ich verstehe nicht wie das Volumen so ansteigen kann:

root@pvem-1:~# zfs get used datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 used 5.50T -
root@pvem-1:~# zfs get usedbysnapshots datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 usedbysnapshots 6.06G -

Lösche alle Snapshost "for snapshot in `zfs list -H -t snapshot | cut -f 1`; do zfs destroy $snapshot; done"

sieht es so aus:

root@pvem-1:~# zfs get usedbysnapshots datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 usedbysnapshots 0B -
root@pvem-1:~# zfs get used datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 used 3.48T -

und lege ich einen von hand an:

root@pvem-1:~# zfs snapshot datapool/vm-520-disk-2@test
root@pvem-1:~# zfs get used datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 used 5.49T -
root@pvem-1:~# zfs get usedbysnapshots datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 usedbysnapshots 11.7M -

Ich verstehe nicht, warum der used Wert so hochgeht, ich Bruchteil einer Sekunde? Das macht mir meine Speicherplanung schnell zunichte. Das HD läuft in einem Windows 2019 System, hat jemand eine Idee, woran es liegt?

root@pvem-1:~# zfs get all datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 type volume -
datapool/vm-520-disk-2 creation Thu Dec 12 10:51 2019 -
datapool/vm-520-disk-2 used 5.49T -
datapool/vm-520-disk-2 available 4.56T -
datapool/vm-520-disk-2 referenced 3.48T -
datapool/vm-520-disk-2 compressratio 1.03x -
datapool/vm-520-disk-2 reservation none default
datapool/vm-520-disk-2 volsize 1.95T local
datapool/vm-520-disk-2 volblocksize 8K default
datapool/vm-520-disk-2 checksum on default
datapool/vm-520-disk-2 compression on inherited from datapool
datapool/vm-520-disk-2 readonly off default
datapool/vm-520-disk-2 createtxg 1351496 -
datapool/vm-520-disk-2 copies 1 default
datapool/vm-520-disk-2 refreservation 2.01T local
datapool/vm-520-disk-2 guid 18033385482363057717 -
datapool/vm-520-disk-2 primarycache all default
datapool/vm-520-disk-2 secondarycache all default
datapool/vm-520-disk-2 usedbysnapshots 21.5M -
datapool/vm-520-disk-2 usedbydataset 3.48T -
datapool/vm-520-disk-2 usedbychildren 0B -
datapool/vm-520-disk-2 usedbyrefreservation 2.01T -
datapool/vm-520-disk-2 logbias latency default
datapool/vm-520-disk-2 objsetid 80552 -
datapool/vm-520-disk-2 dedup off default
datapool/vm-520-disk-2 mlslabel none default
datapool/vm-520-disk-2 sync standard default
datapool/vm-520-disk-2 refcompressratio 1.03x -
datapool/vm-520-disk-2 written 7.33M -
datapool/vm-520-disk-2 logicalused 1.25T -
datapool/vm-520-disk-2 logicalreferenced 1.25T -
datapool/vm-520-disk-2 volmode default default
datapool/vm-520-disk-2 snapshot_limit none default
datapool/vm-520-disk-2 snapshot_count none default
datapool/vm-520-disk-2 snapdev hidden default
datapool/vm-520-disk-2 context none default
datapool/vm-520-disk-2 fscontext none default
datapool/vm-520-disk-2 defcontext none default
datapool/vm-520-disk-2 rootcontext none default
datapool/vm-520-disk-2 redundant_metadata all default
datapool/vm-520-disk-2 encryption off default
datapool/vm-520-disk-2 keylocation none default
datapool/vm-520-disk-2 keyformat none default
datapool/vm-520-disk-2 pbkdf2iters 0 default

 

[fiona]

Hallo,
hier ist (auf Englisch) beschrieben warum das so ist. Zusammengefasst: refreservation bei ZFS stellt sicher, dass immer so viel Speicher für das Datenobjekt selbst vorhanden ist. Und Snapshots sind als eigene Datenobjekte bei dieser Rechnung ausgenommen. Andernfalls könntest du ja nicht deine virtuelle Platte komplett mit neuen Daten überschreiben ohne mehr Speicher als reserviert ist zu beanspruchen.
Ändern kannst Du das Verhalten, indem reservation statt refreservation gesetzt wird, aber dann teilt sich deine virtuelle Platte den reservierten Speicher mit ihren Snapshots.

 

[kunstlust]

Hallo,
hier ist (auf Englisch) beschrieben warum das so ist. Zusammengefasst: refreservation bei ZFS stellt sicher, dass immer so viel Speicher für das Datenobjekt selbst vorhanden ist. Und Snapshots sind als eigene Datenobjekte bei dieser Rechnung ausgenommen. Andernfalls könntest du ja nicht deine virtuelle Platte komplett mit neuen Daten überschreiben ohne mehr Speicher als reserviert ist zu beanspruchen.
Ändern kannst Du das Verhalten, indem reservation statt refreservation gesetzt wird, aber dann teilt sich deine virtuelle Platte den reservierten Speicher mit ihren Snapshots.

oot@pvem-1:~# zfs list -o space -r datapool/vm-520-disk-2 -t all
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
datapool/vm-520-disk-2 7.04T 7.24T 0B 5.23T 2.01T 0B
datapool/vm-520-disk-2@testa - 0B - - - -
datapool/vm-520-disk-2@zfs-auto-snap_frequent-2019-12-17-1500 - 0B - - - -

Kann ich die Inkludierten Snapshost löschen? Wie ist das zu vermeiden? Sicher liegt das an zfs-autonsnapshot und einigen hin und her beim Löschen der Snapshost.

 

[fiona]

Scheint als wären die Snapshots nicht der einzige Faktor hier. Die Snapshots erklären nur einen Teil vom benutzten Speicher und zwar, dass USEDREFRESERV=2.01T ist. Natürlich kannst Du die Snapshots löschen, wenn Du sie nicht benötigst.

Aber obwohl volsize=1.95T ist, ist USEDDS=5.23T und referenced 3.48T (bei deinem ersten Post). Dieser Overhead sollte mit den Details des Setups zusammenhängen. Wie genau wurde der Pool angelegt? Dieser Bug-Report könnte hilfreich sein (insbesondere die letzten paar Kommentare). Du könntest ein paar Test-Volumes mit verschiedenen Werten für volblocksize anzulegen, Daten reinschreiben und schauen, wie die sich verhalten.

 

[kunstlust]

Scheint als wären die Snapshots nicht der einzige Faktor hier. Die Snapshots erklären nur einen Teil vom benutzten Speicher und zwar, dass USEDREFRESERV=2.01T ist. Natürlich kannst Du die Snapshots löschen, wenn Du sie nicht benötigst.

Aber obwohl volsize=1.95T ist, ist USEDDS=5.23T und referenced 3.48T (bei deinem ersten Post). Dieser Overhead sollte mit den Details des Setups zusammenhängen. Wie genau wurde der Pool angelegt? Dieser Bug-Report könnte hilfreich sein (insbesondere die letzten paar Kommentare). Du könntest ein paar Test-Volumes mit verschiedenen Werten für volblocksize anzulegen, Daten reinschreiben und schauen, wie die sich verhalten.

Ich habe bei ersten mal eine Raiz3 angelegt, diesmal habe ich eine Z2 gewählt, per "zpool create -f -o 'ashift=12' datapool raidz2 xxxx"
ich habe das Volumen gelöscht und eine neue HD per Webgui hinzugefügt. Das Problem entsteht aber dennoch immer wieder. Ich habe die Daten wieder in Windows darauf kopiert:

root@pvem-1:~# zfs get all datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 type volume -
datapool/vm-520-disk-2 creation Tue Dec 17 20:23 2019 -
datapool/vm-520-disk-2 used 5.53T -
datapool/vm-520-disk-2 available 8.74T -
datapool/vm-520-disk-2 referenced 3.28T -
datapool/vm-520-disk-2 compressratio 1.00x -
datapool/vm-520-disk-2 reservation none default
datapool/vm-520-disk-2 volsize 1.95T local
datapool/vm-520-disk-2 volblocksize 8K default
datapool/vm-520-disk-2 checksum on default
datapool/vm-520-disk-2 compression off default
datapool/vm-520-disk-2 readonly off default
datapool/vm-520-disk-2 createtxg 12451 -
datapool/vm-520-disk-2 copies 1 default
datapool/vm-520-disk-2 refreservation 2.01T local
datapool/vm-520-disk-2 guid 11878311446678211306 -
datapool/vm-520-disk-2 primarycache all default
datapool/vm-520-disk-2 secondarycache all default
datapool/vm-520-disk-2 usedbysnapshots 242G -
datapool/vm-520-disk-2 usedbydataset 3.28T -
datapool/vm-520-disk-2 usedbychildren 0B -
datapool/vm-520-disk-2 usedbyrefreservation 2.01T -
datapool/vm-520-disk-2 logbias latency default
datapool/vm-520-disk-2 objsetid 3043 -
datapool/vm-520-disk-2 dedup off default
datapool/vm-520-disk-2 mlslabel none default
datapool/vm-520-disk-2 sync standard default
datapool/vm-520-disk-2 refcompressratio 1.00x -
datapool/vm-520-disk-2 written 5.43G -
datapool/vm-520-disk-2 logicalused 1.32T -
datapool/vm-520-disk-2 logicalreferenced 1.23T -
datapool/vm-520-disk-2 volmode default default
datapool/vm-520-disk-2 snapshot_limit none default
datapool/vm-520-disk-2 snapshot_count none default
datapool/vm-520-disk-2 snapdev hidden default
datapool/vm-520-disk-2 context none default
datapool/vm-520-disk-2 fscontext none default
datapool/vm-520-disk-2 defcontext none default
datapool/vm-520-disk-2 rootcontext none default
datapool/vm-520-disk-2 redundant_metadata all default
datapool/vm-520-disk-2 encryption off default
datapool/vm-520-disk-2 keylocation none default
datapool/vm-520-disk-2 keyformat none default
datapool/vm-520-disk-2 pbkdf2iters 0 default

 

[kunstlust]

Ich habe bei ersten mal eine Raiz3 angelegt, diesmal habe ich eine Z2 gewählt, per "zpool create -f -o 'ashift=12' datapool raidz2 xxxx"
ich habe das Volumen gelöscht und eine neue HD per Webgui hinzugefügt. Das Problem entsteht aber dennoch immer wieder. Ich habe die Daten wieder in Windows darauf kopiert:

root@pvem-1:~# zfs get all datapool/vm-520-disk-2
NAME PROPERTY VALUE SOURCE
datapool/vm-520-disk-2 type volume -
datapool/vm-520-disk-2 creation Tue Dec 17 20:23 2019 -
datapool/vm-520-disk-2 used 5.53T -
datapool/vm-520-disk-2 available 8.74T -
datapool/vm-520-disk-2 referenced 3.28T -
datapool/vm-520-disk-2 compressratio 1.00x -
datapool/vm-520-disk-2 reservation none default
datapool/vm-520-disk-2 volsize 1.95T local
datapool/vm-520-disk-2 volblocksize 8K default
datapool/vm-520-disk-2 checksum on default
datapool/vm-520-disk-2 compression off default
datapool/vm-520-disk-2 readonly off default
datapool/vm-520-disk-2 createtxg 12451 -
datapool/vm-520-disk-2 copies 1 default
datapool/vm-520-disk-2 refreservation 2.01T local
datapool/vm-520-disk-2 guid 11878311446678211306 -
datapool/vm-520-disk-2 primarycache all default
datapool/vm-520-disk-2 secondarycache all default
datapool/vm-520-disk-2 usedbysnapshots 242G -
datapool/vm-520-disk-2 usedbydataset 3.28T -
datapool/vm-520-disk-2 usedbychildren 0B -
datapool/vm-520-disk-2 usedbyrefreservation 2.01T -
datapool/vm-520-disk-2 logbias latency default
datapool/vm-520-disk-2 objsetid 3043 -
datapool/vm-520-disk-2 dedup off default
datapool/vm-520-disk-2 mlslabel none default
datapool/vm-520-disk-2 sync standard default
datapool/vm-520-disk-2 refcompressratio 1.00x -
datapool/vm-520-disk-2 written 5.43G -
datapool/vm-520-disk-2 logicalused 1.32T -
datapool/vm-520-disk-2 logicalreferenced 1.23T -
datapool/vm-520-disk-2 volmode default default
datapool/vm-520-disk-2 snapshot_limit none default
datapool/vm-520-disk-2 snapshot_count none default
datapool/vm-520-disk-2 snapdev hidden default
datapool/vm-520-disk-2 context none default
datapool/vm-520-disk-2 fscontext none default
datapool/vm-520-disk-2 defcontext none default
datapool/vm-520-disk-2 rootcontext none default
datapool/vm-520-disk-2 redundant_metadata all default
datapool/vm-520-disk-2 encryption off default
datapool/vm-520-disk-2 keylocation none default
datapool/vm-520-disk-2 keyformat none default
datapool/vm-520-disk-2 pbkdf2iters 0 default

Ich lege nun mal eine per zfs create -V 2T -o volblocksize=128k -o compression=off datapool/vm-520-disk-2 an und werde mit Windows es erneut befühlen. Klar geht das auch mit dd, aber ich denke es löst das Problem, bringt aber mit sich, dass ich alle Volumen von Hand anpassen mus, oder?

 

[fiona]

Ich lege nun mal eine per zfs create -V 2T -o volblocksize=128k -o compression=off datapool/vm-520-disk-2 an und werde mit Windows es erneut befühlen. Klar geht das auch mit dd, aber ich denke es löst das Problem, bringt aber mit sich, dass ich alle Volumen von Hand anpassen mus, doer?

Für schon bestehende Volumes leider ja. Damit neue Volumes eine andere Blockgröße bekommen, kann in der GUI unter Datacenter > Storage > "Name vom ZFS Storage" > Edit oder direkt in /etc/pve/storage.cfg bei dem ZFS Storage die Option blocksize angepasst werden.

 

[kunstlust]

Für schon bestehende Volumes leider ja. Damit neue Volumes eine andere Blockgröße bekommen, kann in der GUI unter Datacenter > Storage > "Name vom ZFS Storage" > Edit oder direkt in /etc/pve/storage.cfg bei dem ZFS Storage die Option blocksize angepasst werden.

Danke Fabian.

Die Blockgröße ist aber auch eine Leistungsfrage, ist also eine Blockgröße von 128k nicht zu hoch? Nach meinen Messungen mit winsat geht sie mit 128k gegenüber 8k sehr hoch:

Beide auf demselben Datapool mit 20X1TB SSD von Intel, werden nicht angesprochen aus Windows, als keine Verluste durch andere Diesnte.

Befehl: winsat disk -drive e:


8K HD mit 256GB, default ohne Anpassung
Disk Random 16.0 Read 144.88 MB/s 7.4
> Disk Sequential 64.0 Read 6255.66 MB/s 9.9
> Disk Sequential 64.0 Write 2487.26 MB/s 9.1
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.206 ms 8.6
> Latenz: 95. Perzentil 0.749 ms 8.5
> Latenz: Maximum 10.094 ms 7.9
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.204 ms 8.9
> Gesamtausführungszeit 00:00:05.52

128k HD mit 2TB von Hand angelegt, wie oben beschrieben

> Disk Random 16.0 Read 452.54 MB/s 8.2
> Disk Sequential 64.0 Read 5923.42 MB/s 9.8
> Disk Sequential 64.0 Write 2637.26 MB/s 9.2
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.148 ms 8.7
> Latenz: 95. Perzentil 0.270 ms 8.8
> Latenz: Maximum 2.898 ms 8.7
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.146 ms 8.9
> Gesamtausführungszeit 00:00:05.34

Hat es auch negative Folgen, evt. SQL DBs? Ich denke, die 16K sind ausreichend, werden die 16K genutzt, soweit ich die Maschine verschiebe und nach Änderung auf 16k zurückholen?


https://forum.proxmox.com/threads/zfs-is-block-size-actually-record-size.55897/

 

[fiona]

Danke Fabian.

Die Blockgröße ist aber auch eine Leistungsfrage, ist also eine Blockgröße von 128k nicht zu hoch? Nach meinen Messungen mit winsat geht sie mit 128k gegenüber 8k sehr hoch:

Beide auf demselben Datapool mit 20X1TB SSD von Intel, werden nicht angesprochen aus Windows, als keine Verluste durch andere Diesnte.

Befehl: winsat disk -drive e:


8K HD mit 256GB, default ohne Anpassung
Disk Random 16.0 Read 144.88 MB/s 7.4
> Disk Sequential 64.0 Read 6255.66 MB/s 9.9
> Disk Sequential 64.0 Write 2487.26 MB/s 9.1
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.206 ms 8.6
> Latenz: 95. Perzentil 0.749 ms 8.5
> Latenz: Maximum 10.094 ms 7.9
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.204 ms 8.9
> Gesamtausführungszeit 00:00:05.52

128k HD mit 2TB von Hand angelegt, wie oben beschrieben

> Disk Random 16.0 Read 452.54 MB/s 8.2
> Disk Sequential 64.0 Read 5923.42 MB/s 9.8
> Disk Sequential 64.0 Write 2637.26 MB/s 9.2
> Durchschnittliche Lesezeit mit sequenziellen Schreibvorgängen0.148 ms 8.7
> Latenz: 95. Perzentil 0.270 ms 8.8
> Latenz: Maximum 2.898 ms 8.7
> Durchschnittliche Lesezeit bei zufallsgesteuerten Schreibvorgängen0.146 ms 8.9
> Gesamtausführungszeit 00:00:05.34

Hat es auch negative Folgen, evt. SQL DBs? Ich denke, die 16K sind ausreichend, werden die 16K genutzt, soweit ich die Maschine verschiebe und nach Änderung auf 16k zurückholen?


https://forum.proxmox.com/threads/zfs-is-block-size-actually-record-size.55897/

Ich würde auch erst mal bei einer kleineren Blockgröße bleiben und nicht sofort aufs Maximum erhöhen. Wenn der Speicher-Overhead immer noch zu groß ist, kann ja nochmal nachgebessert werden (solange genug Speicher da ist, um das Volumen zu kopieren).

Ich glaube mit Maschine hin- und hermigrieren geht es leider nicht, da im Hintergrund zfs send/recv benutzt wird und die Eigenschaften des Volumen erhalten bleiben.

Ich sehe 2 Varianten:
1. selber neue Volumes anlegen und dann mit dd die Daten rüberkopieren (Vorsicht ist geboten!).
2. (temporär) eine neue ZFS Storage anzulegen: zfs create datapool/newblocksize und dann mit der Option für die Blockgröße zu PVE hinzufügen: pvesm add zfspool <name> --pool datapool/newblocksize --blocksize 16K. Dann die Volumen z.B. mit Move Disk in der GUI auf die neue Storage verschieben.

 

[kunstlust]

Ich habe das Problem mit der Umste

Ich würde auch erst mal bei einer kleineren Blockgröße bleiben und nicht sofort aufs Maximum erhöhen. Wenn der Speicher-Overhead immer noch zu groß ist, kann ja nochmal nachgebessert werden (solange genug Speicher da ist, um das Volumen zu kopieren).

Ich glaube mit Maschine hin- und hermigrieren geht es leider nicht, da im Hintergrund zfs send/recv benutzt wird und die Eigenschaften des Volumen erhalten bleiben.

Ich sehe 2 Varianten:
1. selber neue Volumes anlegen und dann mit dd die Daten rüberkopieren (Vorsicht ist geboten!).
2. (temporär) eine neue ZFS Storage anzulegen: zfs create datapool/newblocksize und dann mit der Option für die Blockgröße zu PVE hinzufügen: pvesm add zfspool <name> --pool datapool/newblocksize --blocksize 16K. Dann die Volumen z.B. mit Move Disk in der GUI auf die neue Storage verschieben.

Durch Clonen der VM wird die neuen Blockgröße des Pools genutzt, also ist es in nicht ganz so wild, kostet nur eben Zeit. Ich bleibe bei 16k dort ist der Overhead unter 10%

 

[fiona]

Ich habe das Problem mit der Umste


Durch Clonen der VM wird die neuen Blockgröße des Pools genutzt, also ist es in nicht ganz so wild, kostet nur eben Zeit.

Stimmt, klonen ist natürlich einfacher

 

[kunstlust]

Ich habe nun auf einem anderen System erneut ein Problem mit der Größe des Volumens, ich denke es spielt eine Rolle, das ich einem mal die VSS unter Windows nutzen und zum anderen Snapshots im ZFS mache.

root@pve1:~# zfs get all datapool/vm-211-disk-1
NAME PROPERTY VALUE SOURCE
datapool/vm-211-disk-1 type volume -
datapool/vm-211-disk-1 creation Fri Apr 10 9:15 2020 -
datapool/vm-211-disk-1 used 8.40T -
datapool/vm-211-disk-1 available 6.32T -
datapool/vm-211-disk-1 referenced 3.40T -
datapool/vm-211-disk-1 compressratio 1.00x -
datapool/vm-211-disk-1 reservation none default
datapool/vm-211-disk-1 volsize 2.93T local
datapool/vm-211-disk-1 volblocksize 16K -
datapool/vm-211-disk-1 checksum on default
datapool/vm-211-disk-1 compression off default
datapool/vm-211-disk-1 readonly off default
datapool/vm-211-disk-1 createtxg 1342751 -
datapool/vm-211-disk-1 copies 1 default
datapool/vm-211-disk-1 refreservation 3.56T local
datapool/vm-211-disk-1 guid 4524153431869035614 -
datapool/vm-211-disk-1 primarycache all default
datapool/vm-211-disk-1 secondarycache all default
datapool/vm-211-disk-1 usedbysnapshots 1.44T -
datapool/vm-211-disk-1 usedbydataset 3.40T -
datapool/vm-211-disk-1 usedbychildren 0B -
datapool/vm-211-disk-1 usedbyrefreservation 3.56T -
datapool/vm-211-disk-1 logbias latency default
datapool/vm-211-disk-1 objsetid 84872 -
datapool/vm-211-disk-1 dedup off default
datapool/vm-211-disk-1 mlslabel none default
datapool/vm-211-disk-1 sync standard default
datapool/vm-211-disk-1 refcompressratio 1.00x -
datapool/vm-211-disk-1 written 27.7M -
datapool/vm-211-disk-1 logicalused 4.03T -
datapool/vm-211-disk-1 logicalreferenced 2.84T -
datapool/vm-211-disk-1 volmode default default
datapool/vm-211-disk-1 snapshot_limit none default
datapool/vm-211-disk-1 snapshot_count none default
datapool/vm-211-disk-1 snapdev hidden default
datapool/vm-211-disk-1 context none default
datapool/vm-211-disk-1 fscontext none default
datapool/vm-211-disk-1 defcontext none default
datapool/vm-211-disk-1 rootcontext none default
datapool/vm-211-disk-1 redundant_metadata all default
datapool/vm-211-disk-1 encryption off default
datapool/vm-211-disk-1 keylocation none default
datapool/vm-211-disk-1 keyformat none default
datapool/vm-211-disk-1 pbkdf2iters 0 default

Ich habe das System schon einmal kopiert, aber leider ist es ja schon ein 16K Volumen. Ich nutze ein Raidz1

root@pve1:~# zfs list -o space
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
datapool 2.76T 11.3T 0B 153K 0B 11.3T
datapool/vm-211-disk-0 3.98T 1.55T 888M 339G 1.22T 0B
datapool/vm-211-disk-1 6.32T 8.40T 1.44T 3.40T 3.56T 0B

Die Disk hat eigentlich nur 3TB

datapool/vm-211-disk-1@zfs-auto-snap_weekly-2020-04-12-0447 531G - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_weekly-2020-04-19-0447 307G - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-24-0425 38.4G - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-25-0425 139M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-26-0425 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_weekly-2020-04-26-0447 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-27-0425 938M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-28-0425 1.30G - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-29-0425 791M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1417 313M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1517 1.13G - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1617 59.6M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1717 16.8M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1817 1.49M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-1917 773K - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-2017 409K - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-2117 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-2217 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-29-2317 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0017 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0117 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0217 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0317 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0417 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_daily-2020-04-30-0425 0B - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0517 3.67M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0617 9.25M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0717 13.4M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0817 12.5M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-0917 16.9M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-1017 8.89M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-1117 17.0M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-1217 25.4M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_frequent-2020-04-30-1245 16.2M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_frequent-2020-04-30-1300 15.0M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_frequent-2020-04-30-1315 9.64M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_hourly-2020-04-30-1317 6.82M - 3.40T -
datapool/vm-211-disk-1@zfs-auto-snap_frequent-2020-04-30-1330 5.30M - 3.40T -

Ich glaube es liegt an den VSS von Windows, dass so große Sprünge enstehen, kopiert wird dort jedenfalls nicht so viel.

Hat jemand eine Idee?

 

[fiona]

datapool/vm-211-disk-1 refreservation 3.56T local

root@pve1:~# zfs list -o space
NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
datapool/vm-211-disk-1 6.32T 8.40T 1.44T 3.40T 3.56T 0B

Hat jemand eine Idee?

Das Volumen selbst ist 3.40T groß und, es gibt eine refreservation von 3.56T (so viel Platz ist reserviert, damit das Volumen im Bedarfsfall komplett überschrieben werden kann). Weil es Snapshots gibt, die Reservierung aber für das Volumen selbst gilt, sind zusätzlich zu den 3.40T, noch 3.56T reserviert. Die Snapshots selbst brauchen 1.44T (die relativen Änderungen zwischen den Snapshots). Wenn Du diese drei Werte addierst, kommst du auf 8.40T.

 

[kunstlust]

Das Volumen selbst ist 3.40T groß und, es gibt eine refreservation von 3.56T (so viel Platz ist reserviert, damit das Volumen im Bedarfsfall komplett überschrieben werden kann). Weil es Snapshots gibt, die Reservierung aber für das Volumen selbst gilt, sind zusätzlich zu den 3.40T, noch 3.56T reserviert. Die Snapshots selbst brauchen 1.44T (die relativen Änderungen zwischen den Snapshots). Wenn Du diese drei Werte addierst, kommst du auf 8.40T.

Hallo Fabian,

ich verstehe aber nicht wie die USEDREFRESERV entstehen, auf anderem Systemen ist das nicht so, obwohl die Systeme mit 16K über die Gui angelegt werden. Ich habe keine bewusste Anpassung vorgenommen, mir ist bekannt, dass ich das beim Anlegen eines Subvolumens das in ZFS setzen kann, ich verstehe aber nicht, warum dies bei dem einem System so ist und bei einem anderen nicht.
Sollte also die HD komplett im zweiten System überschrieben werden und nicht mehr per Snapshot gerettet werden können?

NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
rpool/data/vm-527-disk-2 5.72T 1.94T 33.1G 1.90T 0B 0B

Ich glaube etwas gefunden zu haben, ich habe den Pool zpool create -f -o 'ashift=12' datapool raidz1 angelegt, liegt dort der Fehler dran. Der Pool der von proxmox bei der Installation angelegt wird, nutzt kein USEDREFRESERV , der Datapool schon.

 

[fiona]

Hallo Fabian,

ich verstehe aber nicht wie die USEDREFRESERV entstehen, auf anderem Systemen ist das nicht so, obwohl die Systeme mit 16K über die Gui angelegt werden. Ich habe keine bewusste Anpassung vorgenommen, mir ist bekannt, dass ich das beim Anlegen eines Subvolumens das in ZFS setzen kann, ich verstehe aber nicht, warum dies bei dem einem System so ist und bei einem anderen nicht.

Sollte also die HD komplett im zweiten System überschrieben werden und nicht mehr per Snapshot gerettet werden können?

NAME AVAIL USED USEDSNAP USEDDS USEDREFRESERV USEDCHILD
rpool/data/vm-527-disk-2 5.72T 1.94T 33.1G 1.90T 0B 0B

Ich glaube etwas gefunden zu haben, ich habe den Pool zpool create -f -o 'ashift=12' datapool raidz1 angelegt, liegt dort der Fehler dran. Der Pool der von proxmox bei der Installation angelegt wird, nutzt kein USEDREFRESERV , der Datapool schon.

Von der zfs man page:

For volumes, specifies the logical size of the volume. By default, creating a volume establishes a reservation of equal size. For storage pools with a version number of 9 or higher, a refreservation is set instead. Any
changes to volsize are reflected in an equivalent change to the reservation (or refreservation). The volsize can only be set to a multiple of volblocksize, and cannot be zero.

The reservation is kept equal to the volume's logical size to prevent unexpected behavior for consumers. Without the reservation, the volume could run out of space, resulting in undefined behavior or data corruption, depending
on how the volume is used. These effects can also occur when the volume size is changed while it is in use (particularly when shrinking the size). Extreme care should be used when adjusting the volume size.

Though not recommended, a "sparse volume" (also known as "thin provisioned") can be created by specifying the -s option to the zfs create -V command, or by changing the value of the refreservation property (or reservation
property on pool version 8 or earlier) after the volume has been created. A "sparse volume" is a volume where the value of refreservation is less than the size of the volume plus the space required to store its metadata. Con‐
sequently, writes to a sparse volume can fail with ENOSPC when the pool is low on space. For a sparse volume, changes to volsize are not reflected in the refreservation. A volume that is not sparse is said to be "thick
provisioned". A sparse volume can become thick provisioned by setting refreservation to auto.

Was ist die Ausgabe von den folgenden Kommandos?

zfs get all rpool/data/vm-527-disk-2
zfs list -o space rpool/data/vm-527-disk-2 -r -t all

 

[kunstlust]

Von der zfs man page:


Was ist die Ausgabe von den folgenden Kommandos?

zfs get all rpool/data/vm-527-disk-2
zfs list -o space rpool/data/vm-527-disk-2 -r -t all

Hallo Fabian,

die refreservation werden bei rpool wohl auf none gesetzt, soweit ich das jetzt verstanden haben, kann ich das im Fall des ersten Systems ändern, per zfs set refreservation=256g datapool/vm-211-disk-1, was hat das für Auswirkungen? Ist das im laufenden System möglich?

Welche Einstellung sind nach deiner Meinung den Sinnvoll? Ich habe ja nun meine Erfahrungen raidz3 und 8K Blöcken gemacht und habe das entsprechen angepasst, was ich bei der Anlage eben nicht betacht habe, sind refreservation, somit ist ein System eben schnell voll.

 

[fiona]

Hallo Fabian,

die refreservation werden bei rpool wohl auf none gesetzt

Ist die Storage in PVE als sparse konfiguriert (in der GUI als Thin Provisioning geführt)? Das würde erklären, warum refreservation nicht gesetzt wird. PVE benutzt diese Option, um zu entscheiden, ob neue Volumen als sparse also eben ohne Reservierung angelegt werden. Bei ZFS ist das mit der Reservierung keine Eigenschaft vom Pool, sondern Volumen-spezifisch.

kann ich das im Fall des ersten Systems ändern, per zfs set refreservation=256g datapool/vm-211-disk-1, was hat das für Auswirkungen? Ist das im laufenden System möglich?

Ja, das sollte man immer ändern können, ist nur eine Reservierung. Mit dem obigen Kommando ändert sich die Reservierung für die einzelne Disk. Wenn Du es auf dem gesamten Pool ändern willst, schlage ich vor sparse (bzw. Thin Provisioning) zu benutzen. Das ändert allerdings nicht die bestehenden Volumen, für diese muss man händisch refreservation auf none setzen. Dann ist allerdings zu beachten, dass immer genügend Speicherplatz auf dem Pool vorhanden ist. Weil wenn eine VM ein Volumen mit Snapshot besitzt und Änderungen schreibt, wird neuer Speicher vom Pool benutzt (die alten Daten werden ja noch vom Snapshot benötigt).

Welche Einstellung sind nach deiner Meinung den Sinnvoll? Ich habe ja nun meine Erfahrungen raidz3 und 8K Blöcken gemacht und habe das entsprechen angepasst, was ich bei der Anlage eben nicht betacht habe, sind refreservation, somit ist ein System eben schnell voll.

Hängt immer vom Verwendungszweck ab. Bei Thin Provisioning ist der Vorteil, dass nur Daten, die wirklich da sind, Platz brauchen. Der Nachteil ist, dass man in Situationen kommen kann, wo mehr Speicher benötigt würde, als vorhanden ist.