9.3 NFS client bug?

[Rick Macklem]

Garrett Wollman wrote:
> <<On Tue, 7 Oct 2014 18:16:24 -0400 (EDT), Rick Macklem
> <rmacklem at uoguelph.ca> said:
> 
> > ps: I would like to hear what happens when you test against a UFS
> > volume.
> 
> We don't have any UFS volumes, and this 96-drive file server is not
> likely ever to have any.
> 
> FWIW, I now have a packet capture of the complete test, taken from
> the
> server side, if anyone wants to look at it in detail.
> 
> The inner loop of the "sequential delete" benchmark looks like this
> (slightly simplified):
> 
>     while(1)
>     {
>       file_ent = readdir(d);
>       if(file_ent == NULL)
>         break;
>       if(file_ent->d_name[0] != '.')
>       {
>         if(unlink(file_ent->d_name))
>         {
>           fprintf(stderr, "Can't delete file %s\n",
>           file_ent->d_name);
>           return -1;
>         }
>         count++;
>       }
>     }
>     closedir(d);
> 
> This makes me wonder if there isn't some issue with the NFS
> VOP_READDIR losing its place in the presence of interleaved deletes.
> fts(3) won't see this as it reads the whole directory at once (for
> sorting, if requested) before invoking the callback on each entry.
> 
Yep. As noted in the other reply, an unlink() inside a loop on
readdir() has never worked for NFS on FreeBSD, as far as I know.
It's related to the handling of directory offset cookies, but I
can't remember all the details.

rick

> -GAWollman
> 
>