[Gluster-devel] write-behind bug with ftruncatz (was: Re: cache problem?)

[Anand Avati]

Emmanuel,
  Can you give some more info about the happening writes and truncates. Are
they all happening on the same FD? Is it possible to get paste strace -f
output of the ftpd performing writes on the gluster mount?

Avati

On Sat, Jul 16, 2011 at 5:49 PM, Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Emmanuel Dreyfus <manu at netbsd.org> wrote:
>
> > client# md5 gnusrc.tgz
> > MD5 (gnusrc.tgz) = 471a73c374ec2b5733571c01647a69d5
> >
> > server# md5 /export/wd3a/tmp/gnusrc.tgz
> > MD5 (/export/wd3a/tmp/gnusrc.tgz) = cf03446a7f31713002ef3b74020b173f
>
> Here are the results of my investigations. It seems this is caused on
> the client, by reordering of ftruncate() and write() by
> performance/write-behind
>
> Above write-behind, we get this:
> write(sizeA, offsetA)
> ftruncate(offsetB)
> write(sizeB, offsetB)
> write(sizeC, offsetC)
> write(sizeD, offsetD)
>
> And below, this turns into:
> write(sizeA, offsetA)
> write(sizeB, offsetB)
> write(sizeC, offsetC)
> ftruncate(offsetB)
> write(sizeD, offsetD)
>
> Result is that data between offsetB and offsetD is filled with zeros.
>
> Removing the performance/write-behind xlator on the client fixes the
> problem.
>
> Nobody else got this problem? It may be NetBSD-specific, since the
> ftruncate() come from FUSE SETATTR issued by the NetBSD kernel to update
> the file size. I could filter out such messages, but I am not sure it
> would not have side effects.
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
>
> _______________________________________________
> 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/20110717/3f89162d/attachment-0003.html>