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 (fed...@eyal.emu.id.au)
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
