<div dir="ltr">It is cleaner to implement it as a separate fop. The complexity of overloading writev() is unnecessary. There would be a whole bunch of new if/else condititions to be introduced in existing code, and modules like write-behind, stripe etc. where special action is taken in multiple places based on size (and offset into the buffer), would be very delicate error prone changes.<div>
<br></div><div>That being said, I still believe the FOP interface should be similar to SCSI write_same, something like this:</div><div><br></div><div>int fop_write_same (call_frame_t *frame, xlator_t *this, fd_t *fd, void *buf, size_t len, off_t offset, int repeat);</div>
<div><br></div><div>and zerofill would be a gfapi wrapper around write_same:</div><div><br></div><div>int zerofill (call_frame_t *frame, xlator_t *this, fd_t *fd, off_t offset, int len)</div><div>{</div><div> char zero[1] = {0};</div>
<div><br></div><div> return fop_write_same (frame, this, fd, zero, 1, offset, len);</div><div>}</div><div><br></div><div>Avati</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 10:28 PM, M. Mohan Kumar <span dir="ltr"><<a href="mailto:mohan@in.ibm.com" target="_blank">mohan@in.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anand Avati <<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>> writes:<br>
<br>
Hi Shishir,<br>
<br>
Its possible to overload writev FOP for achieving zerofill<br>
functionality. Is there any open issues with this zerofill functionality<br>
even after overloading in writev?<br>
<div class="HOEnZb"><div class="h5"><br>
> Shishir,<br>
> Is this in reference to the dht open file rebalance (of replaying the<br>
> operations to the destination server)? I am assuming so, as that is<br>
> something which has to be handled.<br>
><br>
> The other question is how should fallocate/discard be handled by self-heal<br>
> in AFR. I'm not sure how important it is, but will be certainly good to<br>
> bounce some ideas off here. Maybe we should implement a fiemap fop to query<br>
> extents/holes and replay them in the other serverl?<br>
><br>
> Avati<br>
><br>
><br>
><br>
> On Tue, Aug 13, 2013 at 10:49 PM, Bharata B Rao <<a href="mailto:bharata.rao@gmail.com">bharata.rao@gmail.com</a>>wrote:<br>
><br>
>> Hi Avati, Brian,<br>
>><br>
>> During the recently held gluster meetup, Shishir mentioned about a<br>
>> potential problem (related to fd migration etc) in the zerofill<br>
>> implementation (<a href="http://review.gluster.org/#/c/5327/" target="_blank">http://review.gluster.org/#/c/5327/</a>) and also<br>
>> mentioned that same/similar issues are present with fallocate and<br>
>> discard implementations. Since zerofill has been modelled on<br>
>> fallocate/discard, I was wondering if it would be possible to address<br>
>> these issues in fallocate/discard first so that we could potentially<br>
>> follow the same in zerofill implementation.<br>
>><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>
> 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>
</div></div></blockquote></div><br></div>