[ZFS] ZVOL neemt 2x de toegewezen ruimte in beslag

[Perphide]

Beste tweakers,

Ik heb een NAS (TrueNAS) met daarin wat harde schijven.
Nu heb ik daar in TrueNAS een pool op gemaakt die effectief 4 TB heeft.

Ik heb echter gelezen, dat je een pool niet meer dan 80% mag toewijzen ivm overhead/block storage.
En je mag hem zelfs niet meer dan 50% toewijzen wanneer je er een iSCSI volume op wilt draaien.
Dit laatste doe ik.

Dus ik heb een pool van 4 TB.
Met daarop een ZVOL van 1 TB gemaakt om klein te beginnen. Ik kon immers groeien tot 2 TB om aan de 50% regel te voldoen.

Nu zie ik echter dat door de tijd heen het ZVOL gegroeid is tot over 2 TB.
En de opslag in het iSCSI volume die op dit ZVOL staat is slechts 500 GB.

- Ik heb een boel snapshots, maar als ik die verwijder zie ik geen grote afname in gebruik (5% na verwijderen van een heleboel snapshots)
- Ik heb het iSCSI volume wel redelijk vaak volgepompt en weer opgeschoond, is dat wellicht de oorzaak?

Na veel Google werk kom ik terecht in rekenmodellen en aanverwante zaken, maar geen uitleg hoe en waarom mijn ZVOL zo uit zijn voegen barst.

Kan iemand dit verklaren/uitleggen?

[Giesber]

Plaats misschien eens een screenshot van het Storage > Pools scherm, dat geeft al een hoop informatie over het ruimtegebruik van de NAS.

[dcm360]

Waarschijnlijk ontbreekt er ergens of op meerdere plaatsen in de keten ondersteuning voor TRIM/UNMAP. Vergelijkbaar met SSD's, weet ZFS niet welke blocks op de virtuele disk niet meer in gebruik zijn, en kan de ruimte dus niet vrijgeven zonder TRIM/UNMAP. Het opschonen van het volume heeft je dan alle tijd geen ruimte teruggegeven, maar vanwege snapshots waarschijnlijk ruimte gekost.

[Perphide]

Dank voor jullie reactie.
Even ter uitleg: in mijn tekst heb ik als voorbeeld een 4TB pool gebruikt met 1TB toegewezen aan een ZVOL waarvan 500GB in gebruik is.

In mijn screenshot zal je zien dat de getallen iets anders zijn, in de initiele post was het aan de hand van deze getallen eenvoudiger uit te leggen.

Mijn pool bevat circa 21TB, daarvan is nu 6TB toegewezen aan het ZVOL.
Het ZVOL bevat een iSCSI VMFS die 5TB van deze 6TB heeft toegewezen.
Op de VMFS datastore staat 1.85TB van de 5TB.

Dit is de screenshot zoals gevraagd:




Worden jullie hier wijs van?
Ik namelijk niet echt.
Ik begrijp dat de pool nog 11.82TB beschikbaar heeft; dat klopt ook lijkt mij. Ik heb circa 21TB en het ZVOL gebruikt circa 9TB. Maar daarna kan ik het niet rijmen.
Het ZVOL van 6TB neemt 9TB in beslag? (snapshots?) en zou nog bjina 18TB hebben aan ruimte?

Is dit wellicht een rekensom die rekening houdt met de inhoud van 1.85TB? (~21TB - 1.85 = 17.90TB?)

[ElMacaroni]

Schaamteloze topic-hijack...

Proxmox met ZFS, en ik ben

root@proxmox:~# zpool list
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
zfspool4tb  3.62T  1.45T  2.17T        -         -     5%    40%  1.00x    ONLINE  -

root@proxmox:~# zpool status
   pool: zfspool4tb
 state: ONLINE
  scan: scrub repaired 0B in 02:40:43 with 0 errors on Sun May  9 03:04:44 2021
config:

        NAME                                     STATE     READ WRITE CKSUM
        zfspool4tb                               ONLINE       0     0     0
          mirror-0                               ONLINE       0     0     0
            ata-WDC_WD4003FRYZ-01F0DB0_V1HV889G  ONLINE       0     0     0
            ata-WDC_WD4003FRYZ-01F0DB0_V1HV7XTG  ONLINE       0     0     0

errors: No known data errors

root@proxmox:~# zfs list -t all
NAME                                        USED  AVAIL     REFER  MOUNTPOINT
zfspool4tb                                 3.48T  29.6G     1.54G  /zfspool4tb
zfspool4tb/vm-109-disk-0                   3.46T  2.04T     1.40T  -
zfspool4tb/vm-109-disk-0@Snapshot20210513  45.3G      -     1.40T  -
zfspool4tb/vm-109-disk-0@Snapshot20210606   379M      -     1.40T  -
zfspool4tb/vm-109-state-Snapshot20210513   12.9G  37.5G     4.95G  -
zfspool4tb/vm-109-state-Snapshot20210606   12.9G  38.3G     4.14G  -

In de VM 109: 
[root@sme92 ~]# fdisk -l /dev/sda

Disk /dev/sda: 2147.5 GB, 2147483648000 bytes
255 heads, 63 sectors/track, 261083 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005ad8e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          32      256000   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2              32      261084  2096894976   fd  Linux raid autodetect
[root@sme92 ~]# dmesg | grep sda
sd 2:0:0:0: [sda] 4194304000 512-byte logical blocks: (2.14 TB/1.95 TiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 63 00 00 08
sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2
sd 2:0:0:0: [sda] Attached SCSI disk
md: bind<sda2>
md: bind<sda1>

In de webinterface van Proxmox staat idd zfspool4tb nagenoeg vol.
Maar er staat maar 1 VMdisk op, RAW, 2.15TB Ik zou verwachten nog 1.4TB vrij te hebben...
Waar gaat het mis met mijn begrip?

[zzattack]

Het verwijderen van snapshots zoals je gedaan hebt zou wel eens heel zinloos kunnen zijn. Snapshots gaan nl. pas data 'innemen' zodra content verwijderd wordt van het normale filesystem. De data die je verwijdert is niet weg zo lang er tenminste 1 snapshot aan refereert.

Stel dat je dagelijkse snapshots maakt van je filesystem waar je vanaf dag 1 een hoop data op hebt staan. Deze data verwijder je op dag 10. Eind van de maand heb je 30 snapshots, dan zul je zien dat weggooien van de laatste 20 qua vrijkomende storage helemaal niks uithaalt. Als je met zfs list -t snapshot kijkt welke snapshot een hoop data refereert dan is dat die van dag 10, terwijl dag 1-9 geen extra ruimte kosten. Echter, zodra je snapshot van dag 10 weggooit zul je merken dat die van dag 9 nu als meest recent refererende snapshot wat ruimte "kost". Kortom, om goed op te schonen moeten alle referenties aan oude data weggehaald worden.

[ElMacaroni]

root@proxmox:~# zfs list -o space
NAME                                      AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
zfspool4tb                                29.6G  3.48T        0B   1.54G             0B      3.48T
zfspool4tb/vm-109-disk-0                  2.04T  3.46T     46.7G   1.40T          2.01T         0B
zfspool4tb/vm-109-state-Snapshot20210513  37.5G  12.9G        0B   4.95G          7.93G         0B
zfspool4tb/vm-109-state-Snapshot20210606  38.3G  12.9G        0B   4.14G          8.74G         0B

Ik zie een zfspool4tb/vm-109-disk-0 met 2.04T available en 3.46T gebruik.
Hoe kan dat rijmen met de VM die een disksize heeft van /dev/sda: 2147.5 GB ?

[Thralas]

ElMacaroni schreef op dinsdag 8 juni 2021 @ 23:22:

root@proxmox:~# zfs list -o space
NAME                                      AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
zfspool4tb                                29.6G  3.48T        0B   1.54G             0B      3.48T
zfspool4tb/vm-109-disk-0                  2.04T  3.46T     46.7G   1.40T          2.01T         0B
zfspool4tb/vm-109-state-Snapshot20210513  37.5G  12.9G        0B   4.95G          7.93G         0B
zfspool4tb/vm-109-state-Snapshot20210606  38.3G  12.9G        0B   4.14G          8.74G         0B

Ik zie een zfspool4tb/vm-109-disk-0 met 2.04T available en 3.46T gebruik.
Hoe kan dat rijmen met de VM die een disksize heeft van /dev/sda: 2147.5 GB ?

Oud, maar ik herinnerde me dit topic toen ik er zojuist zelf tegenaanliep.

Het antwoord is simpel: als je een thick provisioned zvol (de default) aanmaakt wordt refreservation gezet. Dit is de ruimte voor references van (o.a.?) snapshots.

Uit de handleiding van Oracle:

If refreservation is set, a snapshot is only allowed if sufficient unreserved pool space exists outside of this reservation to accommodate the current number of referenced bytes in the dataset.

Stel dat je je hele zvol volschrijft, een snapshot maakt en dan de hele zvol opnieuw beschrijft dan heb je effectief 2x de ruimte in gebruik. Op het moment van snapshotten moet je dus 'budget' hebben voor alles dat (uniek) referenced is, dat zou immers opnieuw geschreven kunnen worden. Dat is waar ZFS hier rekening mee houdt, als dat niet hoeft dan moet je je zvol thin provisioned maken, maar dan bestaat het risico dat writes mislukken als je pool out of space is.

De crux om het te begrijpen is de notie dat snapshots 'geen ruimte innemen' op het moment van snapshotten, maar afhankelijk van wat er later wordt geschreven dit wel gaan doen.

Je kunt de refreservation property van een bestaande zvol op none zetten om de gereserveerde ruimte vrij te geven.

@Perphide.

[Perphide]

Dankjewel @Thralas voor je bericht en uitleg, heel waardevol!
Ik ga kijken of ik er baat bij heb de refreservation instelling aan te passen.