Strange thing after upgrading a client to kernel-5.7.17, the client is unable to list files/directories from an NFS server running kernel-5.7.15 (NFS v4.2 / Kerberos mounted /home). The files/directories seem to be accessible if I type in their names, but are not available via ls -l.
Reverting the client to kernel-5.7.15 restores the expected behavior (all files/directories are visible again).
Has anyone else see this?
On Sun, 23 Aug 2020 12:11:54 -0500 Anthony Joseph Messina wrote:
Has anyone else see this?
I haven't seen that specific combination. I have seen a possibly stranger thing: There is a virtual machine at work where a test we run does a "cp /nfs/mounted/dir/* ." and one file from /nfs/mounted/dir is always missing after the copy, it just can't see it when expanding the "*" wildcard.
(We have a gazillion virtual machines for testing with a gazillion different linux distro releases, I don't remember which machine has the problem, but it is a pretty old distro of some kind).
On Sunday, August 23, 2020 12:11:54 PM CDT Anthony Joseph Messina wrote:
Strange thing after upgrading a client to kernel-5.7.17, the client is unable to list files/directories from an NFS server running kernel-5.7.15 (NFS v4.2 / Kerberos mounted /home). The files/directories seem to be accessible if I type in their names, but are not available via ls -l.
Reverting the client to kernel-5.7.15 restores the expected behavior (all files/directories are visible again).
Has anyone else see this?
I forgot to add that the NFS server is exporting an XFS filesystem, in case that matters. -A
On 2020-08-24 03:11, Anthony Joseph Messina wrote:
Strange thing after upgrading a client to kernel-5.7.17, the client is unable to list files/directories from an NFS server running kernel-5.7.15 (NFS v4.2 / Kerberos mounted /home). The files/directories seem to be accessible if I type in their names, but are not available via ls -l.
Reverting the client to kernel-5.7.15 restores the expected behavior (all files/directories are visible again).
Has anyone else see this?
Yes. I still have a record of the discussion (not on this list). This is kind of a "me too" saying it does happen and no solution is offered so feel free to stop reading now.
I was migrating a large array between two machines (nfs->local), both running up-to-date f28 with kernel v4.20.17-100.fc28.x86_64. I am rather sure nfs v4 was used.
The two systems are time synced. The source array is busy but not the target.
I used rsync to copy the data (a long running job) between the live arrays. Then I repeated the rsync a few times and noticed that there is one file (always the same one) that at times is copied, and at others is deleted.
In the end I ran a test (on the target) in the source directory (on nfs). Given enough time the file shows up and disappears:
$ while true ; do echo "`date` `ls -l|grep setup.c`" ; sleep 1s ; done Thu Apr 4 18:54:15 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:16 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:17 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:18 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:19 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:20 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:21 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:22 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:23 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:24 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:25 AEDT 2019 -rw-r--r-- 1 500 500 3098 Jun 23 2016 setup.c Thu Apr 4 18:54:26 AEDT 2019 Thu Apr 4 18:54:27 AEDT 2019 Thu Apr 4 18:54:28 AEDT 2019 Thu Apr 4 18:54:29 AEDT 2019 Thu Apr 4 18:54:30 AEDT 2019 Thu Apr 4 18:54:31 AEDT 2019 Thu Apr 4 18:54:32 AEDT 2019 ## the file shows up again later...
So this is not an rsync problem.
I mention then that the path to that file is long /data1/download/vocore/builds/v15.05.1/build_dir/toolchain-mipsel_24kec+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/linux-3.18.23/arch/mips/loongson/common/uart_base.c and includes a symlink half way down this path: linux -> linux-3.18.23
The problem was not resolved but after a final rsync (with no activity on either array) I compared the list of files on both before replacing the old array with the new.
-- Eyal Lebedinsky (fedora@eyal.emu.id.au)
-
Anthony Joseph Messina -
Eyal Lebedinsky -
Tom Horsley