NFS readdirplus on ZFS with > 1 billion files

[Konstantin Belousov]

On Sat, Dec 31, 2016 at 04:26:11AM -0600, Josh Paetzel wrote:
> We've been chasing this bug for a very long time and finally managed to
> pin it down.  When a ZFS dataset has more than 1 billion files on it and
> an NFS client does a readdirplus the file handles for files with high
> znode/inode numbers gets truncated due to a 64 -> 32 bit conversion.
> 
> https://reviews.freebsd.org/D9009
> 
> This isn't a fix so much as a workaround.  From a performance standpoint
> it's the same as if the client mounts with noreaddirplus; sometimes it's
> a win, sometimes it's a lose.  CPU usage does go up on the server a bit.
> 

Can you point to the places in ZFS code where the truncation occur ?
I have no idea about ZFS code, and my question is mainly is the truncation
just occurs due to different types of ino_t and zfs node id, or some code
actively does the range reduction.

My question is in the context of the long-dragging ino64 work, which might
be finished in some visible future.  In particular, I am curious if just
using the patched kernel fixes your issue.  See
https://github.com/FreeBSDFoundation/freebsd/tree/ino64
although I do not make any claim about the state of the code yet.

Your patch, after a review, might be still useful for stable/10 and 11,
since I do not think that ino64 has any bits which could be merged.