From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Benjamin Coddington <bcodding@redhat.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Subject: Re: git regression failures with v6.2-rc NFS client
Thread-Topic: git regression failures with v6.2-rc NFS client
Thread-Index: AQHZNbksRLoeBCG00EyL+s5Kt9KD6665E+wAgAEOhICAABzOgIADD6eA
Date:   Fri, 3 Feb 2023 14:38:26 +0000
Message-ID: <B90C62F2-1D3A-40E0-8E33-8C349C6FFD3D@oracle.com>
References: <9A4A5673-691D-47EC-BC44-C43BE7E50A48@oracle.com>
 <D0404F55-2692-4DB6-8DD6-CAC004331AC1@redhat.com>
 <5FF4061F-108C-4555-A32D-DDBFA80EE4E7@redhat.com>
 <F1833EA0-263F-46DF-8001-747A871E5757@redhat.com>
In-Reply-To: <F1833EA0-263F-46DF-8001-747A871E5757@redhat.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gUgo2959iMPiYNJVAQb33jO+M6CpyCpa5O2RePEX+6pwYu9G/Yf+zZopt6zc?=
 =?us-ascii?Q?Pioo1fxD7thhAyWONpZY25A6VW8Ra0x+rhzToRpvpARSdv5/Qv6XpIYYbCFn?=
 =?us-ascii?Q?HsnERralJQbbwO4rmr477wLp+yXGK15z3FuoUzyAQz52fzDykJBWn9TpNANM?=
 =?us-ascii?Q?WsPsLhFKLQAkgwep8HVm/0o/WnPgLqs8BMjlelpLEod92F2IalGuNKou8oh0?=
 =?us-ascii?Q?SpFOrkdDRE3SQu9bngH78XE06yf/xWZ3FunD9hsjt4uj/TYFiXKBSQN0jtCR?=
 =?us-ascii?Q?FAtPYQd7GQqfkf0UZCOJFxiQx9BZ8fG6CarEjbpsS8GWNHWQpFxJmABhkGRL?=
 =?us-ascii?Q?7bwMVFoYM+uYNQ1H6RkLg6OEQKt21W+qq9jv3OFOt6fGCYqkoRzhKtbX6+pi?=
 =?us-ascii?Q?5dxYLMDNbffxHcuGHUC0R4TMobALnS26kKAfUNnyuxNZhec9rVBSzt2DEZOP?=
 =?us-ascii?Q?3xGbFij03J8FYi7NRH9w4eTbpN2ZNRdF/ohF/ciwla4TghwTEM1jVPwk9SoU?=
 =?us-ascii?Q?RdEjnTOd7voVuVlrZHOFSHQjWg4Fjc0FRk8imvtASVXa8ueaQuozkHiqmNSB?=
 =?us-ascii?Q?ruFXB/79I/78H3syjbCdj510Cj007TDx+/WRqkksN+ZdCdsyORxVl/4Uw7NG?=
 =?us-ascii?Q?MLiVTZJ9Z5YP0p1BL+HsBgGhLptzU9gQ8LIlqxE5ZUupvesh9Ce+HhFyYDXZ?=
 =?us-ascii?Q?MTZe7gFMGOggJ1nGmDzUlyVFzwXk+KhmN7L+DjkDuvjNoIrXMunixq/HuX3K?=
 =?us-ascii?Q?wPTXgtf7KmjIBL72UCwl0BSPSUyVFbroJvmnz1EtilYs0LwtlgTESIIIIErJ?=
 =?us-ascii?Q?h5t2nm0nxNf7+VkrPXCRVvFe9cKUx8AP0sJ6ECHjvhhKVyBDTlCbW7UUQ4nA?=
 =?us-ascii?Q?BT0sdgklWsOb1gcr5PvxJ+1yE+9NFqFVcMMU840Pv3CTd9q1vZAouOYV40hj?=
 =?us-ascii?Q?qX7KUNn9TPsePpNDnSoIbMf6OlMS40LStAVN55KsGNxi38HOkXLCGsqiGn9R?=
 =?us-ascii?Q?NfSCz1YR8t5kt0R34YNUI5Ak8Y5w+O4U//WEB70HjSd6zAOAKFDy1nYLMoEF?=
 =?us-ascii?Q?Vv0LiFt/czDqkL26H3ONeZoc9pTjcgZYcpVtLBbGoi7/4QpR0britz5arQF0?=
 =?us-ascii?Q?ir7GTyIPPEuSLcJn4YTXS53p5n4IFmirps71v/hmz+tuBH/tR6U68VLYr5RA?=
 =?us-ascii?Q?qw5p6RMFe8lNp8U9NkKYt0LsvBoT/LrmxjA5VDib/3Tl7hix+LM/EVOhECpX?=
 =?us-ascii?Q?nivcHeI0J1sAsPgodMQRkmEb4cBDrlWdYOHGt9HvuKy4oVpVmh6ixjwblgml?=
 =?us-ascii?Q?FDWdlvk5KACYF1JYefv/1JuRxRB+smv9MA2PxnmUL2mw17TPcdrRNHomVybX?=
 =?us-ascii?Q?mkBBieCWyOv1jEa4gw00Yo40YKXXyQtBv50CU4ssRoACLtC6Q9GeDQCXhJRT?=
 =?us-ascii?Q?uJLfgM3C4WiYI94V411VcUNHh5QMTk3OdMrf3QeKl+uxEXuFyNz83dF0Eoa1?=
 =?us-ascii?Q?wjE0Hu2R+ifuCVR0XPqZtZSN31rvleJ62GVwe20Aw84PvjEtURPlIT8kTprB?=
 =?us-ascii?Q?NF7H3j/BYL69Kj6KiHvNgoYMimlP+OUXbm4jyHhgu0RKhsEYkn9tZ0kd6u8i?=
 =?us-ascii?Q?/Q=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21524116453F36468C96169018330754@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: GeMaFlxn9pylYO56qo5L4zw1VEpHLGs9L230vIpNyB7+P8ykDhtkq6ON+xPowBwvJS9kFhhlPX9XKjz23I1GjxpfI6rU6kH0ItrE1x6QIi6yvVt34d2T0TEtISYFLsI47JrG2EY5Wr5bucbpZnn3IPo0j72Z5TcUPqnENQ2GmjYxGzZjjDP1B14O6PeSJNjCVZXswuJMhau4FUrMSfbCrX3uYcJWMiVrs4kgTp8cqTpCKBcin7of0AyrDEZBQhOThmyhon3XsjP3HNuBWxALsotKSaRCW4JoXpw8DhOaEernBFxndrWtUyVbPJ3Op5OgxzPwInzS210WIhD+ISso07QWDFUCDaAJKHUzFwodsbSF5OLrY77rFvwxXdZpBwiXzEZ9v8u1T7qT6MXhwrrwwQbqAvool4Apn9aTExbzoaiBA3/0Sj7rVgQwjIuBfwZ4GTJ7IbDVssE+d9ATPJQpViQt8B223OGnnAwZFNkuQanSifdRQmHhB06nbqxc4k84PINblOA4bj1rUn2k5TTfxdjylwLxG9RtnixGvnA7sYcs+4VmVvsGwtlyLKoRIxRuDbO1KKUHq6EEYta1Us0/LvROKYhQ364HVyDIl6nXROt3IPL1HvvHF64nlXeC9xuDF7kFeimZIy4x4s2SLxiNaaPEQwEWu0E5njjDMWO8MbX/wzaL6uIGYCDsgq/IRLKhGIjTdlBS7PgWJgXsoeUFoBeB2/HwIOM0PKLfUA40SGs/NXVYiJydtEngZ0LeglToYke9596AnaYXFKQmZaYKSB/S01R9IQFMnY+xjqOXHxZ9cVo0txu0hBo2nnasmuWSFn/aMaLiSAmw1fPAYeRM4w==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fece572a-c16c-414d-4c9f-08db05f44f38
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2023 14:38:26.1993
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: POfpHo5Sbw+MXtqd0vu3gU7QWoXT7mXnMkmfI2xFICFQ+Gj+k/gOf/Sv8SuZw5SzHztUPHNT7dMlwblDTSVM5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5064
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1
 definitions=2023-02-03_13,2023-02-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=899 phishscore=0
 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 spamscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2302030135
X-Proofpoint-GUID: O1GFd-lIVUcRXFXX4Vg8lG3cmvYQo7fH
X-Proofpoint-ORIG-GUID: O1GFd-lIVUcRXFXX4Vg8lG3cmvYQo7fH
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 1, 2023, at 10:53 AM, Benjamin Coddington <bcodding@redhat.com> wr=
ote:
>=20
> On 1 Feb 2023, at 9:10, Benjamin Coddington wrote:
>>=20
>> Working on a fix..
>=20
> .. actually, I have no idea how to fix this - if tmpfs is going to modify
> the position of its dentries, I can't think of a way for the client to lo=
op
> through getdents() and remove every file reliably.
>=20
> The patch you bisected into just makes this happen on directories with 18
> entries instead of 127 which can be verified by changing COUNT in the
> reproducer.
>=20
> As Trond pointed out in:
> https://lore.kernel.org/all/eb2a551096bb3537a9de7091d203e0cbff8dc6be.came=
l@hammerspace.com/
>=20
>    POSIX states very explicitly that if you're making changes to the
>    directory after the call to opendir() or rewinddir(), then the
>    behaviour w.r.t. whether that file appears in the readdir() call is
>    unspecified. See
>    https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.htm=
l
>=20
> The issue here is not quite the same though, we unlink the first batch of
> entries, then do a second getdents(), which returns zero entries even tho=
ugh
> some still exist.  I don't think POSIX talks about this case directly.
>=20
> I guess the question now is if we need to drop the "ls -l" improvement
> because after it we are going to see this behavior on directories with >1=
7
> entiries instead of >127 entries.

I don't have any suggestions about how to fix your optimization.

Technically I think this counts as a regression; Thorsten seems
to agree with that opinion. It's late in the cycle, so it is
appropriate to consider reverting 85aa8ddc3818 and trying again
in v6.3 or v6.4.


> It should be possible to make tmpfs (and friends) generate reliable cooki=
es
> by doing something like hashing out the cursor->d_child into the cookie
> space.. (waving hands)

Sure, but what if there are non-Linux NFS-exported filesystems=20
that behave this way?


--
Chuck Lever