This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Patch] Workaround for NFS issue when using cross-test-ssh.sh
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Steve Ellcey <sellcey at imgtec dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 12 Feb 2016 23:27:53 +0000
- Subject: Re: [Patch] Workaround for NFS issue when using cross-test-ssh.sh
- Authentication-results: sourceware.org; auth=none
- References: <87ed1335-2bf5-4446-a313-15bf7b959246 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 10 dot 1602122236210 dot 23773 at digraph dot polyomino dot org dot uk> <1455318779 dot 29579 dot 113 dot camel at ubuntu-sellcey>
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