delaywrite test failures

[Jeremy Allison]

On Wed, Feb 05, 2014 at 04:57:58PM +1300, Andrew Bartlett wrote:
> Many of our flaky and autobuild failures are this one:
> 
> [353/1598 in 17m5s] samba3.base.delaywrite(plugin_s4_dc)
> 
> Running test_delayed_write_update1b
> Initial write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> write time Wed Feb  5 04:41:02 2014 CET
> Server updated write time on close (correct)
> UNEXPECTED(failure): samba3.base.delaywrite.update of write time using SET_END_OF_FILE(plugin_s4_dc)
> REASON: _StringException: _StringException: After SET_END_OF_FILE truncate server updated write_time
> after 0.10 seconds(1 sec == 0.25)(wrong!)
> 
> FAILED (1 failures, 0 errors and 0 unexpected successes in 0 testsuites)
> 
> Anybody know what the issue is, do we just need to make it more relaxed?

The relevent code (I remember 'cos I wrote it :-) is checking that
a SET_END_OF_FILE truncate updates the write time happens 'immediately',
where immediately is set as:

        int used_delay = torture_setting_int(tctx, "writetimeupdatedelay", 2000000);
        int normal_delay = 2000000;
        double sec = ((double)used_delay) / ((double)normal_delay);

(where sec ends up as 0.25 probably due to the writetimeupdatedelay setting
in the test scripts)

        if (diff > (0.25 * sec * 0.75)) { /* 0.75 to cope with vmware timing */
			ERROR....

So I'm guessing this needs relaxing some for the test
environment - looks like our 'immediately' is too strict
in the test harness. (0.25 * 0.25 * 0.75 == 0.0625), and
the return seems to take 0.10 :-(.

The same timing contraint is being applied to anything
that changes the file size (SMBwrite truncate, SET_END_OF_FILE truncate,
SET_ALLOCATION_INFO truncate).

Jeremy.