From owner-freebsd-fs@freebsd.org Sat Feb 13 23:08:32 2021 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A57CA53EE8C for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DdQym45l6z3jCd for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 8CAD953EE8B; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) Delivered-To: fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C79653ECA7 for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DdQym3WWkz3j01 for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 67B891F73C for ; Sat, 13 Feb 2021 23:08:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 11DN8W2P022990 for ; Sat, 13 Feb 2021 23:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 11DN8W4q022989 for fs@FreeBSD.org; Sat, 13 Feb 2021 23:08:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Date: Sat, 13 Feb 2021 23:08:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 23:08:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #11 from Rick Macklem --- Ok, so now I see that stripping of d_ino =3D=3D 0 entries must be done below the VOP_READDIR(). When I did r283330 to get rid of the creation of d_ino =3D=3D 0 entries to fill up the block being filled in the buffer cache, I did not adjust uio_offset to indicate the offset of the next block. --> For my 6K/8K case, I could have advanced uio_offset by 8K even though it filled 6K into the buffer cache block. That might have made the caching work? I'll give that a try. --> It helps that read(2) is no longer expected to read directories. man getdirentries should be fixed for the d_off =3D=3D 0 case. I'll come up with a man page patch and stick it on phabricator, because filling in d_off needs some thought for NFS. There may be some cases where the server's directory offset cookie can be used. Ignore trying to revert the change done to UFS in r252438, since the stripping cannot be done above the VOP_READDIR(). Unless both UFS and ZFS had the property that removal of an entry in a directory does not change other directory offsets, it is not worth worrying about. --> It also implies that d_ino =3D=3D 0 dirents will be passed to user space which is not really intended now? At least that's my opinion. (And, yes, it was an aside and a separate issue.) --=20 You are receiving this mail because: You are the assignee for the bug.=