Date: Tue, 7 Oct 2014 21:24:22 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-fs@freebsd.org Subject: Re: 9.3 NFS client bug? Message-ID: <1991198781.60122149.1412731462373.JavaMail.root@uoguelph.ca> In-Reply-To: <21556.28888.523838.856998@khavrinen.csail.mit.edu>
index | next in thread | previous in thread | raw e-mail
Garrett Wollman wrote:
> <<On Tue, 7 Oct 2014 18:16:24 -0400 (EDT), Rick Macklem
> <rmacklem@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
>
>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1991198781.60122149.1412731462373.JavaMail.root>