NFS problem: file doesn't appear in file listing, but can be accessed directly

Rick Macklem rmacklem at uoguelph.ca
Wed Aug 4 00:33:01 UTC 2010


> From: "Markus Gebert" <markus.gebert at hostpoint.ch>
> To: "Attila Nagy" <bra at fsn.hu>
> Cc: freebsd-fs at freebsd.org
> Sent: Tuesday, August 3, 2010 4:47:38 PM
> Subject: Re: NFS problem: file doesn't appear in file listing, but can be accessed directly
> On 03.08.2010, at 16:36, Attila Nagy wrote:
> 
> >> You can try replacing the client and server with the experimental
> >> ones and see if that fixes the problem.
> >> For the client: mount with "-t newnfs" instead of "-t nfs"
> >> For the server: start both mountd and nfsd with the "-e" option
> > Sure. It works with the newnfs client, so it must be either a weird
> > interaction between the FreeBSD server and client (old), or a client
> > bug.
> 
> Have you tried comparing on-the-wire NFS requests and responses
> between newnfs and legacy nfs clients for your test case? Maybe you
> can rule out the former like this. Or at least prove that the server
> actually responds correctly to the READDIR request.
> 
Yep, it would be nice to see what went across the wire, particularly
the case that fails (the regular client). I've got a hunch that the clients
use different readdir sizes by default which will make comparison
tough. Maybe you could try both clients using "readdirsize=32768" as an
argument, so that they're at least reading the dir. in chunks of the same
size.

You can probably tell if the reply on the wire is legit by pulling
it into wireshark. If wireshark thinks the readdir replies are ok and
the filename exists in an entry on it (when the client fails to find
it), that would indicate that the regular client has a bug, I think?

If "-t newnfs" breaks when you change the readdirsize, then it suggests
the server is busted.

If you can capture the failing case with something like:
    tcpdump -s 0 -w xxx host <server>  (if run on the client)
and then email me "xxx" as an attachment, that would be appreciated.
(basically tcpdump the "ls" command that fails.)

rick




More information about the freebsd-fs mailing list