Message ID | 87ed1335-2bf5-4446-a313-15bf7b959246@BAMAIL02.ba.imgtec.org |
---|---|
State | New |
Headers | show |
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).
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. The other option of course is to create a branch and put my changes there for use locally, but I would also like to avoid that if possible since I think doing builds and testing directly on the main branch is preferable to using a local branch. It is too easy to put patches or other fixes on a local branch and never get them upstreamed if you do all your work on local branches. Steve Ellcey sellcey@imgtec.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).
diff --git a/localedata/gen-locale.sh b/localedata/gen-locale.sh index d471086..8b22feb 100644 --- a/localedata/gen-locale.sh +++ b/localedata/gen-locale.sh @@ -37,6 +37,12 @@ generate_locale () # The makefile checks the timestamp of the LC_CTYPE file, # but localedef won't have touched it if it was able to # hard-link it to an existing file. + # + # Touching the localedata directory, which may have been + # created on a remote system, before touching the LC_CTYPE + # file works around an NFS issue that can affect some systems + # when cross-testing. + touch ${common_objpfx}localedata touch ${common_objpfx}localedata/$out/LC_CTYPE else echo "Charmap: \"${charmap}\" Inputfile: \"${input}\"" \ diff --git a/timezone/Makefile b/timezone/Makefile index dee7568..5cdb5ca 100644 --- a/timezone/Makefile +++ b/timezone/Makefile @@ -70,8 +70,14 @@ CFLAGS-zic.c = $(tz-cflags) -Wno-unused-variable # We have to make sure the data for testing the tz functions is available. # Don't add leapseconds here since test-tz made checks that work only without # leapseconds. +# +# Touching the testdata directory, which may have been created on a remote +# system, before accessing the results in $(evaluate-test) works around an +# NFS issue that can affect some systems when cross-testing. + define build-testdata $(built-program-cmd) -d $(testdata) -y ./yearistype $<; \ +touch $(testdata) $(evaluate-test) endef