From: Jason L Tibbitts III <tibbs@math.uh.edu>
To: Wolfgang Walter <linux@stwm.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
linux-nfs@vger.kernel.org, km@cm4all.com,
linux-kernel@vger.kernel.org
Subject: Re: Regression in 5.1.20: Reading long directory fails
Date: Tue, 03 Sep 2019 20:50:39 -0500 [thread overview]
Message-ID: <ufad0ggrfrk.fsf@epithumia.math.uh.edu> (raw)
In-Reply-To: <4198657.JbNDGbLXiX@h2o.as.studentenwerk.mhn.de> (Wolfgang Walter's message of "Tue, 03 Sep 2019 23:37:30 +0200")
I asked the XFS folks who mentioned that the issues with 64 bit inodes
are old, constrained to larger filesystems than what I'm using, not an
issue with nfsv4, and not present on anything but 32bit clients with old
userspace.
In any case, I have been experimenting a bit and somehow the issue seems
to be related to exporting with sec=krb5i:krb5p or sec=krb5i. If I
export with just sec=krb5p, things magically begin to work.
So basically:
[root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts
7685
nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0
(unmount, then re-export with krb5i on the server)
[root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts
ls: reading directory '/home/tester': Input/output error
5623
nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5i,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0
(umount, then re-export with krb5i:krb5p on the server)
[root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts
ls: reading directory '/home/tester': Input/output error
5623
nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5i,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0
(umount, switch back to plain krb5p)
[root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts
7685
nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0
Sometimes the number of files it lists before it fails changes (and in
this case has been as small as a few hundred) but I don't know what
causes it to change.
Anyway, I hope this helps to pinpoint the problem. I now have a really
easy way to reproduce this without having to kick people off of the
server, and if the successes aren't just some kind of false positives
then I guess I also have a workaround. I'm still at a loss as to why a
revert of the readdir changes makes any difference at all here.
- J<
next prev parent reply other threads:[~2019-09-04 1:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 15:08 Regression in 5.1.20: Reading long directory fails Jason L Tibbitts III
2019-08-13 17:00 ` Jason L Tibbitts III
2019-08-22 19:39 ` Jason L Tibbitts III
2019-08-28 17:46 ` J. Bruce Fields
2019-08-28 18:29 ` Jason L Tibbitts III
2019-08-28 18:33 ` J. Bruce Fields
2019-09-03 15:49 ` Jason L Tibbitts III
2019-09-03 18:02 ` Wolfgang Walter
2019-09-03 19:06 ` Jason L Tibbitts III
2019-09-03 19:08 ` Chuck Lever
2019-09-03 21:37 ` Wolfgang Walter
2019-09-04 1:50 ` Jason L Tibbitts III [this message]
2019-09-06 14:48 ` J. Bruce Fields
2019-09-06 20:47 ` Jason L Tibbitts III
2019-09-06 20:50 ` Chuck Lever
2019-09-08 11:39 ` Benjamin Coddington
2019-09-08 15:19 ` Trond Myklebust
2019-09-08 15:48 ` Chuck Lever
2019-09-08 16:47 ` Trond Myklebust
2019-09-08 16:51 ` Chuck Lever
2019-09-11 16:25 ` Benjamin Coddington
2019-09-11 16:39 ` Chuck Lever
2019-09-11 17:26 ` Benjamin Coddington
2019-09-11 17:27 ` Benjamin Coddington
2019-09-11 17:29 ` Chuck Lever
2019-09-11 17:40 ` Benjamin Coddington
2019-09-11 17:43 ` Chuck Lever
2019-09-11 17:59 ` Benjamin Coddington
2019-09-11 17:50 ` Benjamin Coddington
2019-09-11 17:54 ` Chuck Lever
2019-09-12 12:29 ` Benjamin Coddington
2019-09-12 12:53 ` Trond Myklebust
2019-09-12 13:08 ` Benjamin Coddington
2019-09-12 13:13 ` J. Bruce Fields
2019-09-12 13:25 ` Trond Myklebust
2019-09-12 13:35 ` Benjamin Coddington
2019-09-12 13:14 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ufad0ggrfrk.fsf@epithumia.math.uh.edu \
--to=tibbs@math.uh.edu \
--cc=bfields@fieldses.org \
--cc=km@cm4all.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux@stwm.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).