9.3 NFS client bug?

Rick Macklem rmacklem at uoguelph.ca
Tue Oct 7 22:16:26 UTC 2014


Garrett Wollman wrote:
> <<On Tue, 7 Oct 2014 17:06:02 -0400 (EDT), Rick Macklem
> <rmacklem at uoguelph.ca> said:
> 
> >> 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?
> 
> Nope.  (And I want to emphasize that Ubuntu clients don't exhibit the
> problem, so whatever it is, it doesn't appear to be related to the
> backing filesystem on the server.)
> 
Well, not many things in FreeBSD break when the i-node#s get truncated.
fts(3) will complain about a possible loop in the directory structure,
but I'm not aware of much else.

I have no idea what might break in the Ubuntu client for this case.

All I'm saying is that "it works for Ubuntu" suggests that the bug
is in the FreeBSD client (or FreeBSD port of bonnie++), but doesn't
guarantee that there isn't a server side problem being exposed by
the FreeBSD client.

rick
ps: I would like to hear what happens when you test against a UFS volume.

> > Btw, I tried your bonnie++ command on my test machines, but they
> > failed
> > part way through because they couldn't allocate boundary tags. (At
> > least
> > now I can reproduce that easily, although it is the M_NOWAIT case
> > where
> > the thread just loops in the kernel.)
> 
> You really need to get some server-class hardware.  Perhaps the
> Foundation can help?
> 
> I'm currently using the following command, which seems to reproduce
> the problem reliably on my client and server:
> 
> bonnie++ -s 0 -n 144:0:0:1:16384 -u 4294967294 -D
> 
> This minimizes the amount of temporary storage required.
> 
> -GAWollman
> 


More information about the freebsd-fs mailing list