Discard over NFS not working

[danieleg]

Hi, my setup is as follow:

TrueNAS Core 13.0-U1.1 as NFS server
Proxmox 7.1-12 as the hypervisor

I have a dataset shared through NFS to the proxmox box. On TrueNAS I enabled NFSv4 and on proxmox I forced NFSv4.2 and indeed /proc/mounts shows thats it's mounted correctly as NFSv4.2:

Code:

192.168.31.10:/mnt/VG01/VM01 /mnt/pve/VM01 nfs4 rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,nconnect=8,timeo=600,retrans=2,sec=sys,clientaddr=192.168.31.150,local_lock=none,addr=192.168.31.10 0 0

I then created a QEMU virtual disk on the NFS share with the discard option on and attached that disk to a VM. When I try to delete some files stored on that virtual disk from inside the VM, space of the actual .qcow2 file is not deallocated (qemu-img info report the same "disk size" before and after the delete).
I tested this with various combination of virtual controller and with or without the ssd option, both with windows and linux as guest, but unfortunately none of them worked.
From my research this feature was introduced on NFSv4.2 and indeed on linux is working correctly (I made the same tests on ubuntu server 22.04.1 as NFS server).

I'm missing something or is this a bug?

Thank you in advance.

 

[ChrisRJ]

Are you running TrueNAS as a VM inside Proxmox or on a separate machine?

 

[danieleg]

On a separate machine.

 

[anodos]

From my research this feature was introduced on NFSv4.2

Can you reference the section of the relevant RFC where this is specified (or otherwise reference a source for this)?

 

[danieleg]

This is the RFC section where is mentioned: https://www.rfc-editor.org/rfc/rfc7862.html#section-15.4

 

[firemeteor]

I'm also interested at this feature and would like to understand the blocking issue here.
Just came across a news (Source) on FreeBSD hole-punching support.

- Hole-punching support on FreeBSD for turning a contiguous range of bytes into a hole for a given file. With the FreeBSD support, OpenZFS and TMPFS now support hole-punching on this BSD.

Will this be relevant? The ZFS side support is released on v 2.1.5 and the FreeBSD it requires at least v14 (source).

BTW, there is discussion about NFS4.2 support on sparse files / hole-punching here.

 

[BloodyIron]

I'm also interested at this feature and would like to understand the blocking issue here.
Just came across a news (Source) on FreeBSD hole-punching support.


Will this be relevant? The ZFS side support is released on v 2.1.5 and the FreeBSD it requires at least v14 (source).

BTW, there is discussion about NFS4.2 support on sparse files / hole-punching here.

Kinda unreal to revisit the topic closer to my infra overhaul only to find people referencing my own discussion on the topic... haha! What a world XD

Yeah, I will still need this feature... when I get to the position of able to use a modern Free/TrueNAS (loooonnnggggg story). Hoping... "soon" (months-ish away?).

 

[BloodyIron]

Hey folks, hoping to get some iX Systems attention on this topic.

I haven't personally verified or PoC'd the NFS aspect of hole-punching/discard stuff for modern TrueNAS Scale or Core. However, from what I have been reading (multiple sources), the TrueNAS Scale edition (Linux) does seem to correctly handle NFS Hole-Punching/Discard, however TrueNAS Core (FreeBSD) does not.

This functionality has been rather commonplace for multiple years in the usage of NFS servers, be it FreeBSD/Linux/whatever. And I really think that iX Systems should do whatever work is needed to bring it to TrueNAS Core. If this involves FreeBSD devs, or other effort, then so be it. But when dealing with this aspect of storage, it's quite important. And for me, I was leaning towards the Core edition, but now that I have learned of this observed difference, I'm likely to use Scale edition instead.

This lack of functionality has been a problem in my own environment, and for many year I've had to "make do". And I'm not trying to like blame anyone or whatever. However, what I am working towards is doing more and more stuff (scaling up), so this issue is going to magnify over time for me. So I am soon reaching the point where this will be a make/break decision for direction for me. I know I'm not currently a paying customer or whatever, but I am trying to bring attention to the value of this aspect. I don't think it's an unreasonable amount of work to do for this to be brought to the Core ecosystem.

So, what do you think iX folks? :)