Hello Farzad!
On Wednesday 26 November 2008 Farzad FARID wrote:
> I have a strange problem on a system I'm setting up.
>
> As I already explained previously, the server "clusters" share NFS mount
> point right in the middle of the application directory I am versionning.
...
> I then run "fsvs sync-repos". All the file and directory names scroll on
> the screen, including those in ./settings and ./extension.
Of course, as "sync-repos" fetches the list from the repository - and these
directories are versioned.
> 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.
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.
> Apparently "fsvs" hammered the NFS mounted folders so hard that something
> went wrong. The NFS server is a NetApp, that is supposed to be rock solid.
> Even the backup agent, or the "tar cvzf extension.tar.gz ./extension"
> command why run periodically do not wreck the NFS folders.
Well, they go through the directories in another order ... eg. sorted by name,
or in the order they get listed via NFS.
FSVS goes in inode order (which is a magnitude faster on local disks) - maybe
that's incompatible with the NetApp.
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.
> My questions are:
>
> - why did the fsvs commands "sync-repos" and / or "status" scan the 2 NFS
> folders even though I added them to the ignore list? Is it by design?
"sync-repos" didn't scan, it just listed what it got from the repository.
"status" has to, to show you what had changed.
> - I don't know why some NFS folders appear to be wrecked on the client
> machine (even though nothing is wrong with their content, that I can read
> from SERVER1 correctly), but is there a way to "slow fsvs down" so that it
> does not pound on the filesystem too hard?
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.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
