Date: Tue, 7 Oct 2014 19:01:44 -0400 From: Garrett Wollman <wollman@csail.mit.edu> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: 9.3 NFS client bug? Message-ID: <21556.28888.523838.856998@khavrinen.csail.mit.edu> In-Reply-To: <654363730.60050348.1412720184948.JavaMail.root@uoguelph.ca> References: <21556.24590.269326.188103@khavrinen.csail.mit.edu> <654363730.60050348.1412720184948.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
<<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.
-GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21556.28888.523838.856998>