Ok, this may be a bit complex, but...
I have a bunch of files I wanted to make available on a read-only NFS
mount that currently live in a directory under my home directory.
It turns out that the NFS mount is on the same device (it is in /home/nfs)
as my home directory (/home/mks)
So, thinking that it would be good to have the files actually be the
same files, I did the following (names changed to generics)
cp -al /home/mks/sharestuff /home/nfs/mks-stuff
What cp -al does in Linux/GNU land is to copy a tree by rather than
copying any files, it makes hard-links to those files. Directories are
not linked, they are freshly created on the other end.
Anyway, this seems to have worked fine - except... sometimes some of
the files just can not be read at all over NFS. Which files they are
seems to be somewhat random with very consistant behavior. That is, once
it starts to happen, even restarting the NFS service on the server and
the client does not change which files it is that fail.
In the /var/log/messages I get "fh_verify: no root_squashed access at
<filename>"
but the filename is that of that of the file in my home directory!
On the client side I get a "stale NFS file handle"
It looks like it has something to do with the caching of inode within NFS
and then doing a lookup of the filename from the inode and it not being
within the NFS export tree, the NFS server is failing the operation.
To verify this, I had enough disk space to do a normal copy of the tree and
the export worked just fine. Never had a problem since.
Very strange, and very annoying.
I don't have a large enough disk to try this with another FS currently.
(I run everything XFS) so this may not actually be an XFS issue but rather
an NFS issue. However, it does bring up an interesting question:
Is there some way to get all of the possible names an inode lives under?
It would at least allow a work-around to the NFS problem seen here as it
would find that there is at least one location where this is just fine.
Now to pull out some code and dig into it - but then again, it is working
right now and I have some paying work to do.
--
Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@xxxxxxxx
|