[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 <mohan at in.ibm.com> wrote:

> Anand Avati <anand.avati at gmail.com> 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 <bharata.rao at gmail.com
> >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
> >> Gluster-devel at nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> >>
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130906/c512d536/attachment-0001.html>