Date: Sat, 31 Dec 2016 15:33:50 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Josh Paetzel <jpaetzel@fastmail.net> Cc: freebsd-fs@freebsd.org, mckusick@freebsd.org Subject: Re: NFS readdirplus on ZFS with > 1 billion files Message-ID: <20161231133350.GU1923@kib.kiev.ua> In-Reply-To: <1483179971.3381747.833629401.5EF242B8@webmail.messagingengine.com> References: <1483179971.3381747.833629401.5EF242B8@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161231133350.GU1923>