Again problems with sizes in zfs.

[Toni Blanch]

Hello, to see if you can help me please, I have this pool zfs:


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




I have reviewed the snapshots and nothing




I also find no errors in the zpool





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

 

[fabian]

zfs list -o space almacen/vm-142-disk-0 will tell you more - but it's likely overhead because of raidz.

 

[Toni Blanch]

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.

 

[fabian]

could you post zfs get all almacen/vm-142-disk-0 as well (please as text inside [code][/code] tags, not as screenshot)

 

[Toni Blanch]

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)

 

[fabian]

so, as you can see, logicalused is as expected, but actually used is with the overhead stemming from raidz and a small volblocksize.

 

[Toni Blanch]

What options do I have to solve it?

 

[LnxBil]

What options do I have to solve it?

The only option is to not use raidz, but use stripped mirrors.

 

[Toni Blanch]

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?

 

[fabian]

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.

 

[Toni Blanch]

Can you help me change it?

 

[fabian]

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).

 

[Toni Blanch]

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.

 

[fabian]

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.

 

[Toni Blanch]

The problem is that I cannot locate such a large file anywhere, the only option is to empty it and recreate the zvol?

 

[fabian]

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.