[Gluster-devel] ioctl support in GlusterFS

[Anand Avati]

GFAPI should rather expose the FOPs more natively, as separate API calls.
FUSE would need to convert ioctl() into the appropriate fop.

Avati

On Wed, May 8, 2013 at 9:08 AM, Bharata B Rao <bharata.rao at gmail.com> wrote:

> 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 at gmail.com> 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 at gmail.com>
> 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 at nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >
> >
>
>
>
> --
> http://raobharata.wordpress.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130508/56d131e0/attachment-0001.html>