Avati, I agree with you, I guess it's much easier to handle these as different self-contained FOPs rather than a big ioctl. So essentially FUSE layer and libgfapi would receive the actual ioctl and then break it down to the appropriate FOP like zerofill etc and then at last, posix or bd xlator would pass down the right ioctl to the underlying FS or block device. Regards, Bharata. On Wed, May 8, 2013 at 3:05 AM, Anand Avati <anand.avati@xxxxxxxxx> wrote: > 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 > > -- http://raobharata.wordpress.com/
