Re: [Gluster-devel] Issues with fallocate, discard and zerofill

[Anand Avati]

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.

That being said, I still believe the FOP interface should be similar to SCSI write_same, something like this:

int fop_write_same (call_frame_t *frame, xlator_t *this, fd_t *fd, void *buf, size_t len, off_t offset, int repeat);

and zerofill would be a gfapi wrapper around write_same:

int zerofill (call_frame_t *frame, xlator_t *this, fd_t *fd, off_t offset, int len)

{

  char zero[1] = {0};

  return fop_write_same (frame, this, fd, zero, 1, offset, len);

}

Avati

On Thu, Sep 5, 2013 at 10:28 PM, M. Mohan Kumar <address@hidden> wrote:

Anand Avati <address@hidden> writes:

Hi Shishir,

Its possible to overload writev FOP for achieving zerofill
functionality. Is there any open issues with this zerofill functionality
even after overloading in writev?

> Shishir,
> Is this in reference to the dht open file rebalance (of replaying the
> operations to the destination server)? I am assuming so, as that is
> something which has to be handled.
>
> The other question is how should fallocate/discard be handled by self-heal
> in AFR. I'm not sure how important it is, but will be certainly good to
> bounce some ideas off here. Maybe we should implement a fiemap fop to query
> extents/holes and replay them in the other serverl?
>
> Avati
>
>
>
> On Tue, Aug 13, 2013 at 10:49 PM, Bharata B Rao <address@hidden>wrote:
>
>> Hi Avati, Brian,
>>
>> During the recently held gluster meetup, Shishir mentioned about a
>> potential problem (related to fd migration etc) in the zerofill
>> implementation (http://review.gluster.org/#/c/5327/) and also
>> mentioned that same/similar issues are present with fallocate and
>> discard implementations. Since zerofill has been modelled on
>> fallocate/discard, I was wondering if it would be possible to address
>> these issues in fallocate/discard first so that we could potentially
>> follow the same in zerofill implementation.
>>
>> Regards,
>> Bharata.
>> --
>> http://raobharata.wordpress.com/
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel