<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On Tuesday 19 May 2015 08:36 PM, Shyam
wrote:<br>
</div>
<blockquote cite="mid:555B515F.4030807@redhat.com" type="cite">On
05/19/2015 08:10 AM, Raghavendra G wrote:
<br>
<blockquote type="cite">After discussion with Vijaykumar
mallikarjuna and other inputs in this
<br>
thread, we are proposing all quota tests to comply to following
criteria:
<br>
<br>
* use dd always with oflag=append (to make sure there are no
parallel
<br>
writes) and conv=fdatasync (to make sure errors, if any are
delivered to
<br>
application. Turning off flush-behind is optional since
fdatasync acts
<br>
as a barrier)
<br>
<br>
OR
<br>
<br>
* turn off write-behind in nfs client and glusterfs server.
<br>
<br>
What do you people think is a better test scenario?
<br>
<br>
Also, we don't have confirmation on the RCA that parallel writes
are
<br>
indeed the culprits. We are trying to reproduce the issue
locally.
<br>
@Shyam, it would be helpful if you can confirm the hypothesis
:).
<br>
</blockquote>
<br>
Ummm... I thought we acknowledge that quota checks are done during
the WIND and updated during UNWIND, and we have io threads doing
in flight IOs (as well as possible IOs in io threads queue) and we
have 256K writes in the case mentioned. Put together, in my head
this forms a good RCA that we write more than needed due to the in
flight IOs on the brick. We need to control the in flight IOs as a
resolution for this from the application.
<br>
<br>
In terms of actual proof, we would need to instrument the code and
check. When you say it does not fail for you, does the file stop
once quota is reached or is a random size greater than quota?
Which itself may explain or point to the RCA.
<br>
<br>
The basic thing needed from an application is,
<br>
- Sync IOs, so that there aren't too many in flight IOs and the
application waits for each IO to complete
<br>
- Based on tests below if we keep block size in dd lower and use
oflag=sync we can achieve the same, if we use higher block sizes
we cannot
<br>
<br>
Test results:
<br>
1) noac:
<br>
- NFS sends a COMMIT (internally translates to a flush) post
each IO request (NFS WRITES are still with the UNSTABLE flag)
<br>
- Ensures prior IO is complete before next IO request is sent
(due to waiting on the COMMIT)
<br>
- Fails if IO size is large, i.e in the test case being
discussed I changed the dd line that was failing as "TEST ! dd
if=/dev/zero of=$N0/$mydir/newfile_2 *bs=10M* count=1
conv=fdatasync" and this fails at times, as the writes here are
sent as 256k chunks to the server and we still see the same
behavior
<br>
- noac + performance.nfs.flush-behind: off +
performance.flush-behind: off +
performance.nfs.strict-write-ordering: on +
performance.strict-write-ordering: on +
performance.nfs.write-behind: off + performance.write-behind: off
<br>
- Still see similar failures, i.e at times 10MB file is
created successfully in the modified dd command above
<br>
<br>
Overall, the switch works, but not always. If we are to use this
variant then we need to announce that all quota tests using dd not
try to go beyond the quota limit set in a single IO from dd.
<br>
<br>
2) oflag=sync:
<br>
- Exactly the same behavior as above.
<br>
<br>
3) Added all (and possibly the kitches sink) to the test case, as
attached, and still see failures,
<br>
- Yes, I have made the test fail intentionally (of sorts) by
using 3M per dd IO and 2 IOs to go beyond the quota limit.
<br>
- The intention is to demonstrate that we still get parallel IOs
from NFS client
<br>
- The test would work if we reduce the block size per IO
(reliably is a border condition here, and we need specific rules
like block size and how many blocks before we state quota is
exceeded etc.)
<br>
- The test would work if we just go beyond the quota, and then
check a separate dd instance as being able to *not* exceed the
quota. Which is why I put up that patch.
<br>
<br>
What next?
<br>
<br>
</blockquote>
<tt>Hi Shyam, </tt><tt><br>
</tt><tt><br>
</tt><tt>I tried running the test with dd option 'oflag=append' and
didn't see the issue.</tt><tt> Can you please try this option and
see if it works?<br>
</tt><tt><br>
</tt><tt>Thanks,</tt><tt><br>
</tt><tt>Vijay</tt><tt><br>
</tt><br>
<blockquote cite="mid:555B515F.4030807@redhat.com" type="cite">
<blockquote type="cite">
<br>
regards,
<br>
Raghavendra.
<br>
<br>
On Tue, May 19, 2015 at 5:27 PM, Raghavendra G
<<a class="moz-txt-link-abbreviated" href="mailto:raghavendra@gluster.com">raghavendra@gluster.com</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:raghavendra@gluster.com"><mailto:raghavendra@gluster.com></a>> wrote:
<br>
<br>
<br>
<br>
On Tue, May 19, 2015 at 4:26 PM, Jeff Darcy
<<a class="moz-txt-link-abbreviated" href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:jdarcy@redhat.com"><mailto:jdarcy@redhat.com></a>> wrote:
<br>
<br>
> No, my suggestion was aimed at not having parallel
writes. In this case quota
<br>
> won't even fail the writes with EDQUOT because of
reasons explained above.
<br>
> Yes, we need to disable flush-behind along with
this so that errors are
<br>
> delivered to application.
<br>
<br>
Would conv=sync help here? That should prevent any kind
of
<br>
write parallelism.
<br>
<br>
<br>
An strace of dd shows that
<br>
<br>
* fdatasync is issued only once at the end of all writes
when
<br>
conv=fdatasync
<br>
* for some strange reason no fsync or fdatasync is issued at
all
<br>
when conv=sync
<br>
<br>
So, using conv=fdatasync in the test cannot prevent
<br>
write-parallelism induced by write-behind. Parallelism
would've been
<br>
prevented only if dd had issued fdatasync after each write
or opened
<br>
the file with O_SYNC.
<br>
<br>
If it doesn't, I'd say that's a true test failure
somewhere in
<br>
our stack. A
<br>
similar possibility would be to invoke dd multiple times
with
<br>
oflag=append.
<br>
<br>
<br>
Yes, appending writes curb parallelism (at least in
glusterfs, but
<br>
not sure how nfs client behaves) and hence can be used as
an
<br>
alternative solution.
<br>
<br>
On a slightly unrelated note flush-behind is immaterial in
this test
<br>
since fdatasync is anyways acting as a barrier.
<br>
<br>
_______________________________________________
<br>
Gluster-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Gluster-devel@gluster.org"><mailto:Gluster-devel@gluster.org></a>
<br>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
<br>
<br>
<br>
<br>
<br>
--
<br>
Raghavendra G
<br>
<br>
<br>
<br>
<br>
--
<br>
Raghavendra G
<br>
<br>
<br>
_______________________________________________
<br>
Gluster-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
<br>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>