Het grote ZFS topic

[syl765]

Misschien heb je last van de nieuwe space reservation.
Nieuwere pools reserveren iets meer ruimte, het kan zijn dat je hierdoor in de problemen komt.

http://lists.freebsd.org/...2014-November/020429.html
spa_slop_shift is de tunable , even googlelen .

[kaaas]

Edit Ik heb een oorzaak/fix zie einde van mijn post

Ik heb een interessant probleem met zfs on linux.
Ik heb een volle pool (0k vrij) en ik kan er niets meer van verwijderen met bijv een rm.
Dat geeft op zicht niet het is een test omgeving, maar als ik een andere pool op het zelfde systeem net zo vol gooi kan ik gewoon nog bestanden verwijderen. Nu wil ik graag weten wat er mis is, maar ik kan niets vinden dat niet in de haak is. Kunnen jullie helpen met trouble shooten?

Edit ik ben meer geïnteresseerd in wat het probleem is dan in een oplossing. Oplossingen kan ik zelf zo wel verzinnen aangezien het toch test data is.

Scrubben gaat probleemloos geen enkele fout.
De block sum = gelijk aan de space maps

64gb ram
ubuntu 15.10
zfs v0.6.4.2-0ubuntu1.1, ZFS pool version 5000, ZFS filesystem version 5

zpool status

pool: tank0
state: ONLINE
scan: scrub in progress since Mon Jan 11 11:42:15 2016
4.78T scanned out of 21.4T at 691M/s, 7h0m to go
0 repaired, 22.34% done
config:

NAME STATE READ WRITE CKSUM
tank0 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
F0 ONLINE 0 0 0
F3 ONLINE 0 0 0
F2 ONLINE 0 0 0
F1 ONLINE 0 0 0
F7 ONLINE 0 0 0
F6 ONLINE 0 0 0

errors: No known data errors


zpool get all
NAME PROPERTY VALUE SOURCE
tank0 size 21.8T -
tank0 capacity 98% -
tank0 altroot - default
tank0 health ONLINE -
tank0 guid 9034185262091936598 default
tank0 version - default
tank0 bootfs - default
tank0 delegation on default
tank0 autoreplace off default
tank0 cachefile - default
tank0 failmode wait default
tank0 listsnapshots off default
tank0 autoexpand off default
tank0 dedupditto 0 default
tank0 dedupratio 1.00x -
tank0 free 348G -
tank0 allocated 21.4T -
tank0 readonly off -
tank0 ashift 12 local
tank0 comment - default
tank0 expandsize - -
tank0 freeing 0 default
tank0 fragmentation 59% -
tank0 leaked 0 default
tank0 feature@async_destroy enabled local
tank0 feature@empty_bpobj enabled local
tank0 feature@lz4_compress active local
tank0 feature@spacemap_histogram active local
tank0 feature@enabled_txg active local
tank0 feature@hole_birth active local
tank0 feature@extensible_dataset enabled local
tank0 feature@embedded_data active local
tank0 feature@bookmarks enabled local

zfs get all

NAME PROPERTY VALUE SOURCE
tank0 type filesystem -
tank0 creation Mon Dec 21 8:58 2015 -
tank0 used 17.1T -
tank0 available 0 -
tank0 referenced 17.1T -
tank0 compressratio 1.00x -
tank0 mounted yes -
tank0 quota none default
tank0 reservation none default
tank0 recordsize 128K default
tank0 mountpoint /tank0 default
tank0 sharenfs off default
tank0 checksum on default
tank0 compression off default
tank0 atime on default
tank0 devices on default
tank0 exec on default
tank0 setuid on default
tank0 readonly off default
tank0 zoned off default
tank0 snapdir hidden default
tank0 aclinherit restricted default
tank0 canmount on default
tank0 xattr on default
tank0 copies 1 default
tank0 version 5 -
tank0 utf8only off -
tank0 normalization none -
tank0 casesensitivity sensitive -
tank0 vscan off default
tank0 nbmand off default
tank0 sharesmb off default
tank0 refquota none default
tank0 refreservation none default
tank0 primarycache all default
tank0 secondarycache all default
tank0 usedbysnapshots 0 -
tank0 usedbydataset 17.1T -
tank0 usedbychildren 15.8M -
tank0 usedbyrefreservation 0 -
tank0 logbias latency default
tank0 dedup off default
tank0 mlslabel none default
tank0 sync standard default
tank0 refcompressratio 1.00x -
tank0 written 17.1T -
tank0 logicalused 17.1T -
tank0 logicalreferenced 17.1T -
tank0 snapdev hidden default
tank0 acltype off default
tank0 context none default
tank0 fscontext none default
tank0 defcontext none default
tank0 rootcontext none default
tank0 relatime off default
tank0 redundant_metadata all default
tank0 overlay off default


Ok hoe het helemaal zit ben ik nog niet helemaal achter, maar ik heb wel een fix die goed genoeg is om niet meer met het probleem te zitten.
Zfs houd een reserve aan hoe vol je schijf mag zitten. In zfs on linux 0.64 is dat 1,6% vanaf 0.65 is het 3,2 procent. Ik zat op 0,64 en dus op 1,6 procent als ik deze omlaag haal naar ,8% kan ik weer schrijven en bestanden verwijderen. Uiteraard heb ik hem hier na op 3,2 % gezet daar is vast een reden voor dat ze dat verhoogd hebben waarschijnlijk de problemen die ik ondervond.

Het is nog steeds niet duidelijk waarom ik in de ene pool niet meer kan verwijderen en in de andere pool wel terwijl ze beiden vol zitten. Mocht ik dit vinden zal ik het ook posten.

Hoe doe je dit?
Je moet de spa_slop_shift parameter aan passen.
Deze staat bij mij in /sys/module/zfs/paramters/spa_slop_shift in 0,64 is het 6 in 0,65 staat ie op 5
Je komt bij het percentage door 100/2^6 dat is dus 100/64=1,56 % en 100/2^5=3.125 Ik heb hem tijdelijk op 7 gezet want hij stond toen ik mijn disks vol zette op 6.
Je kunt hetm instellen door /etc/modprobe.d/zfs.conf aan te maken en daar de volgende regel in te zetten.
options zfs spa_slop_shift=Getal
Je kunt rebooten om hem te laten gelden of door de zfs module te verwijderen en weer toe te voegen.
Vervolgens kun je de waarde checken door /sys/modules/zfs/paramters/spa_slop_shift uit te lezen.

Ik ga er van uit dat ze spa_slop_shift om hoog hebben gezet om het probleem dat ik heb te voorkomen.
fix is dus zet hem op 5 of installeer ZoL 0,65 waar ie standaard al op 5 staat.

Mocht je trouwens upgraden van 0,64 naar 0,65 check even of je pool minder dan 97% gevuld is anders heb je hommeles die met bovenstaande te fixen.

[ Voor 12% gewijzigd door kaaas op 15-01-2016 13:25 ]

[narotic]

Martinoswebdsgn schreef op zondag 06 maart 2016 @ 20:23:
gaat inderdaad om ZoL op Ubuntu.
Dus gewoon FreeBSD installeren? Pool importeren en daar 1 file aanmaken en terug verwijderen?
Dat zou het moeten doen? En dan blijft de issue opgelost?

Dit is zogenaamde "reserved space", welke sinds ZFS 0.6.5 omhoog gegaan is naar ongeveer 3.2%:

Default reserved space was increased from 1.6% to 3.2% of total pool capacity. This default percentage can be controlled through the new spa_slop_shift module option, setting it to 6 will restore the previous percentage.

Wellicht dat je dus ook even kunt proberen om de module parameter spa_slop_shift tijdelijk op 6 te zetten om wat ruimte vrij te maken. Als files deleten op het moment niet gaat omdat er geen ruimte vrij is, dan wil het trouwens ook wel eens helpen om een paar grote files te overschrijven met lege input in plaats van ze te verwijderen:

echo '' > /some/big/file

[Compizfox]

Thomg schreef op vrijdag 6 oktober 2017 @ 19:53:
Ik gebruik al een jaar of 2 a 3 lang een HDD in zfs mode ( meegenomen van een FreeNAS install ) en heb recent mijn plexserver opengegooid voor mijn vrienden.
Nu mijn schijf wat meer vol begint te raken heb ik me wat meer verdiept in hoe ik nuttiger met de schijf om kan gaan.

Één schijf maar? Of meerdere in RAID?

Nu doe ik wat commando's en zie ik de volgende dingen.
[afbeelding]
Hieruit volgen wat vragen...
Waarom is de overhead zo mallot groot , blijkbaar verlies ik 1/32? Dat is reteveel op een 3,63 TiB schijffie.

Je verliest inderdaad 1/32 aan "slop space", dat klopt. Zie hier. Ik zie alleen niet direct waaruit je dat opmaakt, want ik zie veel meer overhead (0.66 TiB) dan dat. 1/32 van 3.62 TiB is maar 0.11 TiB.

Is er misschien een reden waarom mijn compressratio zo spectaculair... shit is?

Wat voor content staat erop? Als dat content is die al gecomprimeerd is (video's, foto's) dan ga je dat niet verder dan het entropielimiet kunnen comprimeren.

[Thomg]

Compizfox schreef op vrijdag 6 oktober 2017 @ 19:59:
[...]

Één schijf maar? Of meerdere in RAID?

[...]

Je verliest inderdaad 1/32 aan "slop space", dat klopt. Zie hier. Ik zie alleen niet direct waaruit je dat opmaakt, want ik zie veel meer overhead dan dat...

[...]

Wat voor content staat erop? Als dat content is die al gecomprimeerd is (video's, foto's) dan ga je dat niet verder dan het entropielimiet kunnen comprimeren.

Het is 1 4TB HDD.
Enkel ZFS omdat dat standaard was met FreeNAS op dat moment ik te lui was te converteren naar ext4.
En, mja, die extra veiligheid, waarom ook niet he

1/32*3.62=0,113125 ~=~ (681-565)/1000=0,116
Las ook ergens dat dit 1/64 kon zijn? Weet niet of dit zomaar even aangepast kan worden.

Het is een wiswas aan content, van video's en foto's, tot projecten, tot code, tot documenten, tot images.

[ Voor 7% gewijzigd door Thomg op 06-10-2017 20:05 ]

[Compizfox]

Thomg schreef op vrijdag 6 oktober 2017 @ 20:02:
[...]

Het is 1 4TB HDD.
Enkel ZFS omdat dat standaard was met FreeNAS op dat moment ik te lui was te converteren naar ext4.

1/32*3.62=0,113125 ~=~ (681-565)/1000=0,116

Het is een wiswas aan content, van video's en foto's, tot projecten, tot code, tot documenten, tot images.

Je rekent nu met de resterende vrije ruimte, maar die 1/32 is van je totale pool size. Je zou dus maar 3.62/32=0.11 TiB in totaal aan "slop space" kwijt moeten zijn. Niet 1/32 van je resterende ruimte (wat bij jou, waarschijnlijk toevallig, ongeveer het geval is).

Jij bent nu 3.62 - 2.96 = 0.66 TiB in totaal kwijt aan overhead. Geen idee waar dat precies aan opgaat als het maar 1 HDD is...

[ Voor 3% gewijzigd door Compizfox op 06-10-2017 20:12 ]

[Thomg]

Compizfox schreef op vrijdag 6 oktober 2017 @ 20:05:
[...]

Je rekent nu met de resterende vrije ruimte, maar die 1/32 is van je totale pool size. Je zou dus maar 3.62/32=0.11 TiB in totaal aan "slop space" kwijt moeten zijn. Niet 1/32 van je resterende ruimte (wat bij jou, waarschijnlijk toevallig, ongeveer het geval is).

Jij bent nu 0.66 TiB in totaal kwijt aan overhead. Geen idee waar dat precies aan opgaat als het maar 1 HDD is...

Deze delta is statisch, onafhankelijk van hoeveel ik verwijder en toevoeg. Dus ik denk dat dat wel klopt?
Of misschien snap ik het niet helemaal?

Vind 0.66 TiB wel veel die "poef" doet, hoe kom je op dit getal?

Zie dat je je bericht geüpdatet hebt, ik ben die ruimte niet kwijt, deze is nog free (565GB, that is).

[ Voor 6% gewijzigd door Thomg op 06-10-2017 20:09 ]

[Dadona]

ocaj schreef op woensdag 16 september 2020 @ 07:50:
Ik heb nu een schijf waarbij zpool list aangeeft dat er nog 164G vrij is:

code:

zpool list backup
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
backup  4.53T  4.37T   164G        -         -    15%    96%  1.00x    ONLINE  -

maar zfs list geeft nog maar 19G vrij:

code:

zfs list backup
NAME     USED  AVAIL     REFER  MOUNTPOINT
backup  4.37T  19.3G      196K  /backup

Vermoedelijk heb je het antwoord al gevonden. Mocht het niet zo zijn: ZFS reserveert standaard wat ruimte om te kunnen blijven functioneren met weinig resterende ruimte (slop space). Dat gaat sinds een aantal jaar standaard (zoals ook bij jouw setup) om 3.2% van de totale capaciteit van de pool. In jouw geval dus ~4,53*0,032 = ~145GB. Tel daar de 19GB bij op en je komt op de 164GB die je zoekt.

De instelling staat alhier en zal in jouw geval 5 retourneren.

code:

cat /sys/module/zfs/parameters/spa_slop_shift

Door daar 6 van te maken zal de slop space aangepast worden naar 1.6%

code:

echo 6 > /sys/module/zfs/parameters/spa_slop_shif

[nero355]

Bramus2000 schreef op vrijdag 16 december 2022 @ 14:09:
Nu heb ik mijn pool volgeschreven, Ondertussen reeds files gedelete, maar pool blijft vol aangeven.

Hoe groot is je gereserveerde ruimte op de Pool

Check dit effe : Dadona in "Het grote ZFS topic"
Voor meer info zie : Zoeken naar "slop space" in "Het grote ZFS topic"