On Tue, May 19, 2015 at 4:26 PM, Jeff Darcy <jda...@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@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > -- Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel