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