Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp115765ybe; Tue, 3 Sep 2019 18:51:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqyhkuUFdBnRajaB60mOYEpBunB+fcMyEFb5lOc7ufHk2E4u6gbgPALmsui6esLansub7AOn X-Received: by 2002:a63:2903:: with SMTP id p3mr18241982pgp.306.1567561886077; Tue, 03 Sep 2019 18:51:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567561886; cv=none; d=google.com; s=arc-20160816; b=rZf35HiKf8D614wZiDJR4zMgDcukMe3KUR7Kr5lPGE/xOZvSDUkhIvXEzxS3jwEDBz aUVdLdJ4PLCXjtZZxi1lPOl30AcNjHwHISN6z5xhs7JlOdxFW3p6jeDoIkFvSu0lMD4e qI/mxxSATFs6+PoD2hpamgRGXIPJ4euTS6GaV7TLWaNfo8wyfHP45X0xN1FQHLCaaG4P ZWCcXEzrTgTh5SuB/k+I930jUyCQP8vRJyCtad8Q8TNRjwBCpX5bt1ZDk0//tT2ASV3s OewdCBifC7+6+0YAAk6IrRxlxYv68NOZ3XW5dRoUbkD0DqSWA4P/eJjMmZKaa3BAISyf xc5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=etvVYvyfgKDKwDC4w+6971h6F6Qwre0ouEAezvgKvEM=; b=yX+dgwlYcU6Gk3a6Xlb7s1iOG/3qNqN8yYWMzCxPWcyNvsAIe7zZp4osasmX9RInbK vQMcaW6awGrYX+ivgRjCMKl91MP57vUBPICClhu1jlR3wf0XhB8LOBuOUa3z6a/0ZUUV Y6E1Kd6MagcZ5BQe7wMyxaXkpZiMXbN1SbCG3TwDU77SdymfCWVCDEMID1pqPGb/Q2bo U53gPWuehXHNE1d5lFq1+PPiCdAy/x7jL8A0kdkz7CnzwGuW7ihPS/M2nWeax31EvC8w gO84cIHuMgMlKB3npJZ6jqdF+vBwbq+eIpIzf8gLlnISJbTPzONINGFHSYTKvzYvi5ZS 07Og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y8si14729101pfq.15.2019.09.03.18.50.59; Tue, 03 Sep 2019 18:51:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726925AbfIDBu6 (ORCPT + 99 others); Tue, 3 Sep 2019 21:50:58 -0400 Received: from mx1.math.uh.edu ([129.7.128.32]:56502 "EHLO mx1.math.uh.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726589AbfIDBu6 (ORCPT ); Tue, 3 Sep 2019 21:50:58 -0400 Received: from epithumia.math.uh.edu ([129.7.128.2]) by mx1.math.uh.edu with esmtp (Exim 4.92) (envelope-from ) id 1i5KRT-0006fx-6c; Tue, 03 Sep 2019 20:50:54 -0500 Received: by epithumia.math.uh.edu (Postfix, from userid 7225) id 21319801554; Tue, 3 Sep 2019 20:50:39 -0500 (CDT) From: Jason L Tibbitts III To: Wolfgang Walter Cc: "J. Bruce Fields" , linux-nfs@vger.kernel.org, km@cm4all.com, linux-kernel@vger.kernel.org Subject: Re: Regression in 5.1.20: Reading long directory fails References: <4418877.15LTP4gqqJ@stwm.de> <4198657.JbNDGbLXiX@h2o.as.studentenwerk.mhn.de> Date: Tue, 03 Sep 2019 20:50:39 -0500 In-Reply-To: <4198657.JbNDGbLXiX@h2o.as.studentenwerk.mhn.de> (Wolfgang Walter's message of "Tue, 03 Sep 2019 23:37:30 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.9 (--) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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<