<div dir="ltr">GFAPI should rather expose the FOPs more natively, as separate API calls. FUSE would need to convert ioctl() into the appropriate fop.<br><div class="gmail_extra"><br>Avati</div><div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, May 8, 2013 at 9:08 AM, Bharata B Rao <span dir="ltr"><<a href="mailto:bharata.rao@gmail.com" target="_blank">bharata.rao@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Avati,<br>
<br>
I agree with you, I guess it's much easier to handle these as<br>
different self-contained FOPs rather than a big ioctl.<br>
<br>
So essentially FUSE layer and libgfapi would receive the actual ioctl<br>
and then break it down to the appropriate FOP like zerofill etc and<br>
then at last, posix or bd xlator would pass down the right ioctl to<br>
the underlying FS or block device.<br>
<br>
Regards,<br>
Bharata.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, May 8, 2013 at 3:05 AM, Anand Avati <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>> wrote:<br>
> Having an ioctl FOP can be generally ugly. ioctl() is typically a "catch<br>
> all" interface for which other meaningful syscalls do not exist, and ends up<br>
> working out fine in a syscall like situation. However given the variable<br>
> arguments nature of the call, implementing a generic marshalling and RPC and<br>
> detecting/negotiating compatibility of sub-commands between client/server<br>
> can make it tricky for a FOP. You will never see ioctl as an RPC method in<br>
> any system. We should rather have a new FOP for each such new functionality,<br>
> and wire them to appropriate ioctls at the outermost layer (in FUSE and/or<br>
> storage/posix)<br>
><br>
> We need a set of new FOPs in the general area you mention above<br>
><br>
> 1. fallocate()<br>
> 2. discard()<br>
> 3. zerofill()<br>
> 4. splice()<br>
><br>
> This set of FOPs should probably be sufficient to overlay most of the<br>
> functionality in this general area. It will be nice to have them exposed<br>
> through GFAPI and integrated in the QEMU plugin.<br>
><br>
> Avati<br>
><br>
><br>
> On Tue, May 7, 2013 at 9:15 AM, Bharata B Rao <<a href="mailto:bharata.rao@gmail.com">bharata.rao@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> As support for SCSI offloads like WRITE SAME and UNMAP is being made<br>
>> available on Linux via ioctls (BLKZEROUT, BLKDISCARD), the same can be<br>
>> exploited from GlusterFS for virtualization usecase if GlusterFS also<br>
>> supported ioctl as an FOP.<br>
>><br>
>> Is there any historical reason for GlusterFS not supporting ioctl ? I<br>
>> gathered from my brief discussion over irc that there isn't any<br>
>> particular reason for this, but wanted to ask the developer community<br>
>> before we start working on adding ioctl FOP in GlusterFS.<br>
>> Regards,<br>
>> Bharata.<br>
>> --<br>
>> <a href="http://raobharata.wordpress.com/" target="_blank">http://raobharata.wordpress.com/</a><br>
>><br>
>> _______________________________________________<br>
>> Gluster-devel mailing list<br>
>> <a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
>> <a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
<a href="http://raobharata.wordpress.com/" target="_blank">http://raobharata.wordpress.com/</a><br>
</font></span></blockquote></div><br></div></div>