1

I use scp to copy some files to a XFS local partition on a file server host and create a symbolic link to new deployed files locally though SSH. That partition is exported through NFS and mounted on several hosts.

scp new-file-version fileserver:/nfs/exported/path
ssh fileserver ln -s new-file-version /nfs/exported/path/file

If I check for the deployed files and symbolic link locally in the file server everything is fine:

fileserver$ ls -l /nfs/exported/path
lrwxrwxrwx  1 root root  56 Oct 30 12:30 file -> new-file-version
-rwxr-xr-x 11 root root 220 Oct 30 12:34 new-file-version
-rwxr-xr-x 11 root root 220 Oct 30 12:12 previous-file-version

But when I try to see the deployed files or copy them through NFS I get several some Input/output error in the just created symbolic links:

nfsclient$ ls -l /nfs/mounted/path
ls: cannot read symbolic link /nfs/mounted/path/file: Input/output error
lrwxrwxrwx  1 root root  56 Oct 30 12:30 file
-rwxr-xr-x 11 root root 220 Oct 30 12:34 new-file-version
-rwxr-xr-x 11 root root 220 Oct 30 12:12 previous-file-version

The stat command on the NFS mounted path reports this info:

nfsclient$ stat /nfs/mounted/path
  File: '/nfs/mounted/path'
  Size: 175             Blocks: 0          IO Block: 32768  directory
Device: 2ch/44d Inode: 560507638   Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-11-02 14:25:04.677606317 +0100
Modify: 2018-11-02 14:25:28.630755680 +0100
Change: 2018-11-02 14:25:28.630755680 +0100
 Birth: -

Notice that the access time is previous to the modify/change time, in spite of that I have just read the directory contents.

If I retry the operation, it will finally succeed after some attempts:

nfsclient$ ls -l /nfs/mounted/path
lrwxrwxrwx  1 root root  56 Oct 30 12:30 file -> new-file-version
-rwxr-xr-x 11 root root 220 Oct 30 12:34 new-file-version
-rwxr-xr-x 11 root root 220 Oct 30 12:12 previous-file-version

And then stat reports this information with the access time updated:

nfsclient$ stat /nfs/mounted/path
  File: '/nfs/mounted/path'
  Size: 175             Blocks: 0          IO Block: 32768  directory
Device: 2ch/44d Inode: 560507638   Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-11-02 14:25:30.925774294 +0100
Modify: 2018-11-02 14:25:28.630755680 +0100
Change: 2018-11-02 14:25:28.630755680 +0100
 Birth: -

Any clue on why is this happenning?

  • 1
    Possible duplicate of How to follow symlinks in NFS? – Rui F Ribeiro Nov 2 '18 at 11:26
  • 1
    That post is about the path of a symlink read on a NFS partition, not about the temporary problem in reading the symlink that I'm experimenting. – UaT Nov 2 '18 at 11:31
  • Sounds like a NFS caching/revalidation bug (probably) on the client. What kernel version are you running on the client and the server? Try running stat against the directory containing the symlink target or the directory containing the symling itself at various points (before symlink creation, before the first ls, after the error goes away). You'll probably see an old (cached) directory being used for a while until it expires from the attribute cache. – TooTea Nov 2 '18 at 12:18
  • Both clients and server are RHEL7, uname -a provides this string: Linux host 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux – UaT Nov 2 '18 at 13:22
  • If I cd to the /nfs/mounted/path the directory content gets updated. Before the link becomes valid stat on the directory show access time previous to the modify and change time. – UaT Nov 2 '18 at 13:27
0

Well, according to https://bugzilla.redhat.com/show_bug.cgi?id=1416532, it's a bug in RHEL7.3, that was exactly the version we were using.

It has been fixed in kernel kernel-3.10.0-562.el7.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.