Again problems with sizes in zfs.

Toni Blanch

Member
May 8, 2019
27
0
6
49
Hello, to see if you can help me please, I have this pool zfs:
Captura de Pantalla 2020-03-24 a les 23.17.05.png

of 15.31 Tb and marks me as used 14.78 which is 96.52% But the only file I see is 11,70Tb

Captura de Pantalla 2020-03-24 a les 23.17.16.png


I have reviewed the snapshots and nothing

Captura de Pantalla 2020-03-24 a les 23.18.59.png


I also find no errors in the zpool

Captura de Pantalla 2020-03-24 a les 23.19.22.png
Captura de Pantalla 2020-03-24 a les 23.28.19.png


Can you help me find out why an 11Tb file occupies 14Tb? Could it be that there are badly deleted files in the zfs? how can i locate them?
Thank you very much for your help
 
zfs list -o space almacen/vm-142-disk-0 will tell you more - but it's likely overhead because of raidz.
 
But, from 11.7Tb to 14.8? It is a lot of difference, and I'm afraid it will fail, as it already happened to me.

Captura de Pantalla 2020-03-25 a les 7.48.25.png
 
could you post zfs get all almacen/vm-142-disk-0 as well (please as text inside [code][/code] tags, not as screenshot)
 
NAME PROPERTY VALUE SOURCE
almacen/vm-142-disk-0 type volume -
almacen/vm-142-disk-0 creation sáb nov 16 12:12 2019 -
almacen/vm-142-disk-0 used 14,8T -
almacen/vm-142-disk-0 available 508G -
almacen/vm-142-disk-0 referenced 14,8T -
almacen/vm-142-disk-0 compressratio 1.08x -
almacen/vm-142-disk-0 reservation none local
almacen/vm-142-disk-0 volsize 11,7T local
almacen/vm-142-disk-0 volblocksize 8K default
almacen/vm-142-disk-0 checksum on default
almacen/vm-142-disk-0 compression on inherited from almacen
almacen/vm-142-disk-0 readonly off default
almacen/vm-142-disk-0 createtxg 2621042 -
almacen/vm-142-disk-0 copies 1 default
almacen/vm-142-disk-0 refreservation none local
almacen/vm-142-disk-0 guid 5937804140026080512 -
almacen/vm-142-disk-0 primarycache all default
almacen/vm-142-disk-0 secondarycache all default
almacen/vm-142-disk-0 usedbysnapshots 0B -
almacen/vm-142-disk-0 usedbydataset 14,8T -
almacen/vm-142-disk-0 usedbychildren 0B -
almacen/vm-142-disk-0 usedbyrefreservation 0B -
almacen/vm-142-disk-0 logbias latency default
almacen/vm-142-disk-0 dedup off default
almacen/vm-142-disk-0 mlslabel none default
almacen/vm-142-disk-0 sync standard default
almacen/vm-142-disk-0 refcompressratio 1.08x -
almacen/vm-142-disk-0 written 14,8T -
almacen/vm-142-disk-0 logicalused 11,1T -
almacen/vm-142-disk-0 logicalreferenced 11,1T -
almacen/vm-142-disk-0 volmode default default
almacen/vm-142-disk-0 snapshot_limit none default
almacen/vm-142-disk-0 snapshot_count none default
almacen/vm-142-disk-0 snapdev hidden default
almacen/vm-142-disk-0 context none default
almacen/vm-142-disk-0 fscontext none default
almacen/vm-142-disk-0 defcontext none default
almacen/vm-142-disk-0 rootcontext none default
almacen/vm-142-disk-0 redundant_metadata all default
(END)
 
so, as you can see, logicalused is as expected, but actually used is with the overhead stemming from raidz and a small volblocksize.
 
Is there a way to optimize that doesn't consume 14,8Tb when the disk is 11,7
Tb? Now changing from raidz to mirror is impossible, since it is not a manageable size.
Can I change the volblocksize for a bigger one?
 
yes you can, that will alleviate the problem somewhat depending on how big you are willing to go. but it has other downsides, and requires tuning inside the guest otherwise you'll lose a lot of performance (bigger blocksize -> small writes require a read-modify-write cycle of a big block). not that volblocksize needs to be set at volume creation time and cannot be changed afterwards.
 
it can only be set at volume creation time (you can set it in PVE's storage config, then it will be set accordingly for all newly created volumes).
 
What options do I have to solve the problem? I am already 99% full and I am afraid of losing the file.
The file creates it on 12000G and the volume of 15Tb, the truth is that I am afraid that it will continue to grow and eventually break.Captura de Pantalla 2020-03-28 a les 22.03.06.png
 
Last edited:
you need to move it to some other storage, and then recreate it with the new volblocksize. there is no possibility of changing the volblocksize on the fly.
 
The problem is that I cannot locate such a large file anywhere, the only option is to empty it and recreate the zvol?
 
The problem is that I cannot locate such a large file anywhere, the only option is to empty it and recreate the zvol?

if you don't have free sapce anywhere, then yes.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!