Re: [Patch] Workaround for NFS issue when using cross-test-ssh.sh

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 12 Feb 2016, Steve Ellcey wrote:

> On Fri, 2016-02-12 at 22:38 +0000, Joseph Myers wrote:
> > I don't think it makes sense to put such workarounds for a fundamentally 
> > unreliable environment in particular tests.  You simply need to find 
> > appropriate NFS mount settings on all systems involved to ensure that no 
> > problematic caching occurs, or flush caches explicitly in 
> > cross-test-ssh.sh (and I think it will be a lot easier if the build system 
> > exports its filesystem to the test system, rather than both getting a 
> > filesystem from a third system).
> 
> In an ideal world I would agree with you.  But to do that I must
> restrict my builds and my testing to machines I have root access to so
> that I can do the NFS mounts in the required manner.  I have some
> machines like that but I also have access to a second set of machines
> where I cannot change the NFS settings or make other root level changes
> because I share them with other groups, these machines do all have
> access to shared filesystems like /users that live on dedicated NFS
> servers and I could use them for builds and testing if it were not for
> this one problem.

I very much doubt any local changes to a few tests can reliably help here.  
Requiring a coherent filesystem view is just like requiring the test 
system not to suffer from random memory corruption - if you don't have an 
environment that will actually execute the intended programs with the 
intended filesystem view, just about anything in the testsuite will fail 
at random, and putting in a few workarounds (as opposed to explicit hooks 
in cross-test-ssh.sh to insert cache flushes / barriers to force changes 
made on the clients to be visible on the file server, and to force changes 
the server has seen to be visible on the clients, if such operations are 
possible from the command line) is much like automatically retrying tests 
that segfault in case it was unreliable memory, based on a list of the 
tests with the greatest dependence on reliable memory (or like a hook that 
says "this test overheats my processor, so wait X time afterwards for it 
to cool down" - which is obviously a local-only hack).

-- 
Joseph S. Myers
joseph@codesourcery.com