Re: files disappearing from ls on NFS

Hartmut Brandt wrote:
> On Sun, 12 May 2013, Rick Macklem wrote:
> 
> RM>Hartmut Brandt wrote:
> RM>> Hi,
> RM>>
> RM>> I've updated one of my -current machines this week (previous
> update
> RM>> was in
> RM>> february). Now I see a strange effect (it seems only on NFS
> mounts):
> RM>> ls or
> RM>> even echo * will list only some files (strange enough the first
> files
> RM>> from
> RM>> the normal, alphabetically ordered list). If I change something
> in the
> RM>> directory (delete a file or create a new one) for some time the
> RM>> complete
> RM>> listing will appear but after sime time (seconds to a minute or
> so)
> RM>> again
> RM>> only part of the files is listed.
> RM>>
> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is
> RM>> called
> RM>> only once (returning 4096). For a full listing getdirentries is
> called
> RM>> 5
> RM>> times with the last returning 0.
> RM>>
> RM>> I can still open files that are not listed if I know their name,
> RM>> though.
> RM>>
> RM>> The NFS server is a Windows 2008 server with an OpenText NFS
> Server
> RM>> which
> RM>> works without problems to all the other FreeBSD machines.
> RM>>
> RM>> So what could that be?
> RM>>
> RM>I've attached a patch that might be worth trying. It is a "shot in
> the dark",
> RM>but brings the new NFS client's readdir closer to the old one
> (which you
> RM>mentioned still works ok).
> RM>
> RM>Please let me know how it goes, if you have a chance to test it,
> rick
> 
> Hi Rick,
> 
> the patch doesn't help.
> 
> I wrote a small test program, which opens a directory, calls
> getdents(2)
> in a loop and dumps that. I figured out, that the return of the system
> call depends on the buffer size I pass to it. The directory has a
> block
> size of 4k according to fstat(2). If I use that, I get some 300 of the
> almost 500 directory entries. If I use 8k, I get just around 200 and
> if I
> use 16k I get a handfull. If I dump the buffer in this case I see
> 0x200
> bytes filled with directory entries, then a lot of zeros and starting
> from
> 0x1000 again data. This is of course ignored because of the zeros
> before.
> 
And for this case getdents(2) returned 16K? It is normal for getdents(2)
to return less than requested and when end of dir occurs, it should return 0.

But if it returns 16K, there shouldn't be zeroed space in the middle of
it.

And this always occurs or only after you wait a while? (You noted in the
above description that it would be ok for a little while after a directory
change and then would break, which suggests some kind of caching problem.)

rick

> All this looks very strange.
> 
> harti
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"