Hi, On Wednesday 26 November 2008 19:58:22 Philipp Marek wrote: > > > Now I try to run "fsvs status", and it fails with an NFS error! > > > > [EMAIL PROTECTED] fsvs status > > D... 1113 clearlabels.php > > .m.. 1476 settings/binaryfile.ini > > .m.. 6944 settings/browse.ini > > .m.. 821 settings/codetemplate.ini > > [.................] > > .m.. 1296 settings/wordtoimage.ini > > .mC. 31861 settings/siteaccess/site_instit/override.ini.append.php > > N... dir settings/.snapshot > > > > An error occurred: Stale NFS file handle (116) > > in waa__build_tree: chdir(hourly.5) > > Is that reproducible? Else I'd think that FSVS read the parent directory > (and caused the OS to cache the inode), and when it did the chdir() the > directory had changed (because of the other machine) - and the cached inode > was no longer valid.
I can't reproduce it this morning... the inode cache must have been flushed in the meatime. And I had forgotten that, this morning early at 6am, my fsvs autocommit script would run! Fortunately it didn't break anything, although FSVS found local files to be different from the repository even though they are on a shared NFS folder! This is a problem I had already talked about. It is very strange, but it only happens on NFS folders of course. > Could you please run > fsvs st -d | tail -50 > and > strace fsvs st > > and send me the output? Of the strace the last few lines should be > sufficient. I'll do it if the problem happens on another couple of servers that I'm versionning today :) > > I've already seen problems on such boxes - a tar (for backup) that (more or > less reproducible) gets "ENODIR" on chdir() (on different entries) - so > there seems to be some possible problem with the file type reporting. > > Maybe that's a similar problem. Maybe, yes. The procedures and the context here do not leave us any opportunity to update the NetApp OS or play with the NFS mount options. So even if FSVS is not the guilty, I can't do anything to change the setup.. We'll see what happens next. > Not currently. > But you could easily go into waa__build_tree(), hlp__lstat() or > dir__enumerator() and put some usleep() there. > Although I'd think that's the last resort - there should be some other > solution. Thanks for the hint :) But as you say it is a last resort solution, and I'd rather not touch the code to introduce kludges. Regars, -- Farzad FARID / Architecte Open Source - Associé Pragmatic Source / http://www.pragmatic-source.com Tel : +33 9 53 19 21 90 / Mob : +33 6 03 70 65 46 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
