Having an ioctl FOP can be generally ugly. ioctl() is typically a "catch all" interface for which other meaningful syscalls do not exist, and ends up working out fine in a syscall like situation. However given the variable arguments nature of the call, implementing a generic marshalling and RPC and detecting/negotiating compatibility of sub-commands between client/server can make it tricky for a FOP. You will never see ioctl as an RPC method in any system. We should rather have a new FOP for each such new functionality, and wire them to appropriate ioctls at the outermost layer (in FUSE and/or storage/posix)
We need a set of new FOPs in the general area you mention above
1. fallocate()
2. discard()
3. zerofill()
4. splice()
This set of FOPs should probably be sufficient to overlay most of the functionality in this general area. It will be nice to have them exposed through GFAPI and integrated in the QEMU plugin.
Avati