Date: Fri, 12 Feb 2021 14:35:02 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 253428] getdirentries does not work correctly on NFS mounts Message-ID: <bug-253428-3630-qwpyB820dy@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253428-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-253428-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253428 --- Comment #6 from Rick Macklem <rmacklem@FreeBSD.org> --- Just fyi, what I am looking at for the case where the directory offset cookie returned by the server is monotonically increasing is... Replacing uses ig gbincore() with a similar call the uses PCTRIE_LOOKUP_LE() instead of PCTRIE_LOOKUP(). This would allow the directory offset cookies to be used as keys for the block instead of the "logical byte offset" of the converted to UFS-like directory blocks. The problem is that there is no way to know if the directory offset cookies are monotonically increasing until you see them. (Linux does something where the client code checks for a non-monotonically increasing offset then disables the caching optimization if this happens. I am not yet sure if doing this will be practical for what I am starting to code.) I am planning on proposing a new attribute for NFSv4.2 to indicate whether or not the offsets are monotonically increasing, but that will take a long time to get adopted. Once keyed on directory offset cookies, I think the "short block caching issue might get fixed, since I think it was related to the "logical byte offset" of the next block changing when short directory blocks were returned. (Maybe this should be moved to a mailing list?) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253428-3630-qwpyB820dy>