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
On Tue, May 7, 2013 at 9:15 AM, Bharata B Rao <bharata.rao@xxxxxxxxx> wrote:
Hi,
As support for SCSI offloads like WRITE SAME and UNMAP is being made
available on Linux via ioctls (BLKZEROUT, BLKDISCARD), the same can be
exploited from GlusterFS for virtualization usecase if GlusterFS also
supported ioctl as an FOP.
Is there any historical reason for GlusterFS not supporting ioctl ? I
gathered from my brief discussion over irc that there isn't any
particular reason for this, but wanted to ask the developer community
before we start working on adding ioctl FOP in GlusterFS.
Regards,
Bharata.
--
http://raobharata.wordpress.com/
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
