9.3 NFS client bug?

Rick Macklem rmacklem at uoguelph.ca
Tue Oct 7 12:04:44 UTC 2014


Garrett Wollman wrote:
> <<On Fri, 3 Oct 2014 18:10:16 -0400 (EDT), Rick Macklem
> <rmacklem at uoguelph.ca> said:
> 
> > 2 - Try an "oldnfs" mount and see if the old client exhibits the
> > same behaviour.
> 
> Same behavior both old and new.  I'm doing binary search now to try
> to
> minimize the size of the workload that exhibits the issue.
> 
> -GAWollman
> 
By ay chance is your ZFS server allocating a ZFS inode (whatever they
call it) with a fileno/inode# that doesn't fit in 32 bits?
(There is a diagnostic printf w.r.t. this for NFSv4, but not NFSv3,
 so you might try an NFSv4 mount. The printf starts with "NFSv4 fileid > 32..".)

Since d_fileno in "struct dirent" is 32bits, NFS just truncates the
64bit fileid to 32bits (or fills the high order 32bits with 0s for the server).
ZFS is known to generate fileids with non-zero high order 32bits->busted.
(And not at all easy to fix. I actually have a somewhat hackish idea for
 a way to make 64bit d_fileno values work without busting backwards compatibility.
 I think I'll post that to freebsd-fs@ and see what others think?)

rick


More information about the freebsd-fs mailing list