[Gluster-devel] Moratorium on new patch acceptance

[Raghavendra G]

On Tue, May 19, 2015 at 4:26 PM, Jeff Darcy <jdarcy at redhat.com> wrote:

> > No, my suggestion was aimed at not having parallel writes. In this case
> quota
> > won't even fail the writes with EDQUOT because of reasons explained
> above.
> > Yes, we need to disable flush-behind along with this so that errors are
> > delivered to application.
>
> Would conv=sync help here?  That should prevent any kind of write
> parallelism.
>

An strace of dd shows that

* fdatasync is issued only once at the end of all writes when conv=fdatasync
* for some strange reason no fsync or fdatasync is issued at all when
conv=sync

So, using conv=fdatasync in the test cannot prevent write-parallelism
induced by write-behind. Parallelism would've been prevented only if dd had
issued fdatasync after each write or opened the file with O_SYNC.

If it doesn't, I'd say that's a true test failure somewhere in our stack.  A
> similar possibility would be to invoke dd multiple times with oflag=append.
>

Yes, appending writes curb parallelism (at least in glusterfs, but not sure
how nfs client behaves) and hence can be used  as an alternative solution.

On a slightly unrelated note flush-behind is immaterial in this test since
fdatasync is anyways acting as a barrier.

_______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150519/2712eff2/attachment.html>