On Tue, May 19, 2015 at 5:40 PM, Raghavendra G <raghaven...@gluster.com> wrote:
> After discussion with Vijaykumar mallikarjuna and other inputs in this > thread, we are proposing all quota tests to comply to following criteria: > > * use dd always with oflag=append (to make sure there are no parallel > writes) and conv=fdatasync (to make sure errors, if any are delivered to > application. Turning off flush-behind is optional since fdatasync acts as a > barrier) > > OR > > * turn off write-behind in nfs client and glusterfs server. > s/glusterfs server/glusterfs nfs server. > > What do you people think is a better test scenario? > > Also, we don't have confirmation on the RCA that parallel writes are > indeed the culprits. We are trying to reproduce the issue locally. @Shyam, > it would be helpful if you can confirm the hypothesis :). > > regards, > Raghavendra. > > On Tue, May 19, 2015 at 5:27 PM, Raghavendra G <raghaven...@gluster.com> > wrote: > >> >> >> 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 >> > > > > -- > Raghavendra G > -- Raghavendra G
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel