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@xxxxxxxxxxxxxx) _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
