Proposing space management API to perform hole-punching

[Ka Ho Ng]

Hi all,

I am proposing https://reviews.freebsd.org/D28347 for performing space management In FreeBSD. It also depends on https://reviews.freebsd.org/D27194 which is a public KPI addition for doing vm cache cleaning. This proposal is inspired by the discussions around https://reviews.freebsd.org/D5126.

The proposal contains fspacectl(2), VOP_DEALLOCATE(9) and vn_deallocate(9). fspacectl(2) is a space management API that takes a file descriptor, a command value, a range and flags. The system call is responsible for doing space management operations such as punching holes, which is the only operation supported so far. SPACECTL_F_CANEXTEND flag is also provided such that the file size of the affected file would be extended in case the operation range overlaps  with or goes pass file size.

VOP_DEALLOCATE(9) is a VOP call which is to be implemented by file system implementations. File system that supports sparse file could implement this VOP call and wire it with its internal file bmap facilities. A file system provided implementation also needs handle operation range which isn’t aligned to, for instance, file system block size by zeroing the partial allocation units. A fallback implementation that zeroes all the non-hole region within operation range. It is okay to return partial results to prevent holding vnode lock for too long.

vn_deallocate(9) is a public KPI which calls VOP_DEALLOCATE(9) with control over vnode lock and range lock. vn_deallocate(9) also handles the case that VOP_DEALLOCATE(9) returns partial result, and temporarily releases the held vnode lock from time to time in such case internally. 

I also plan to implement VOP_ALLOCATE(9) and the preallocation command within fspacectl(2), and implement posix_fallocate(2) to call fspacectl(2) instead.

In case you are interested in the proposal, please feel free to look into it. :)

Ka Ho