[PATCHES] make delaywrite torture tests more reliable (part 1)

[Andrew Bartlett]

On Thu, 2014-10-02 at 23:32 +0200, Michael Adam wrote:
> On 2014-10-03 at 07:34 +1300, Andrew Bartlett wrote:
> > On Thu, 2014-10-02 at 17:31 +0200, Michael Adam wrote:
> > > Attached find a first patchset to make our delaywrite
> > > torture tests more reliable.
> > > 
> > > This patchset treats the first group of tests
> > > that essentially check whether the write time
> > > is immediately updated by the server after a
> > > truncation/expansion operation.
> > > 
> > > There was a potentially false failure condition
> > > in these tests, where a long running fileinfo
> > > call would let torture think the server did
> > > not update the time immediately. This was a
> > > frequent cause of failure in autobuild.
> > > It should be gone now.
> > > 
> > > The patches treat each of the functions separately,
> > > also doing some additional cleanup work.
> > > 
> > > Review/Comment/push appreciated!
> > 
> > I've reviewed these, and pushed them to autobuild, except for the 3 you
> > mention above, because I need to be convinced as to the correctness.
> 
> Thanks!
> The autobuild failed at the samba4.winbind.struct.domain_info
> test... unrelated.
> 
> > Isn't the issue that we want to know not only that the write time is
> > updated to the correct value, but that it is updated essentially
> > immediately, not some time later?
> 
> Right. But how can we test "immediately"?
> We can just verify that the next fileinfo
> immediately after the truncation call
> reports the updated write time.
> If this first call returns only with some
> delay, this does NOT imply that the server
> hasn't updated the write time immediately.
> It only means that it took the server some
> time to answer the fileinfo call, nothing
> more..
> 
> But the original implementation of the test
> checked the time also for the first call,
> hence resulting in false failures.
> 
> My change avoids the time check for the
> first fileinfo call, i.e. when this first
> call reports updated write time, no matter
> with how much delay, this is treated as success.
> 
> If the first call does not report updated
> write time, then this is failure. We only
> do subsequent calls for some time because
> we want to check whether the server updates
> the time later or not at all (within a
> certain timeout).
> 
> Makes sense?

Ahh.  I clearly didn't look at it with enough context.  This is a
stricter test, and a reasonable one I think.

> > I also removed an extra printf argument in 3 of the torture_comment
> > calls, that caused the compile to break on my system.
> 
> Oh, sorry! I seem to have forgotten to compile-check the
> patchset after a last-minute change to adapt the messages.
> 
> I also updated my branch with the fixed torture_comments,
> including your review tag for all but the above 4 patches.

Thanks.

Reviewed-by: Andrew Bartlett <abartlet at samba.org>

I'll try and autobuild again.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba