patchshaffer@msn.com (Patch) wrote in message
[snip]
> It states that the number of links is 2 instead of 1 that is expected.
> This happens after the LINK-REMOVE portion and then it checks the number
> of links. In looking at traces to the server that fails the client after
> the REMOVE does a ACCESS call to the directory checking permissions and then
> does a LOOKUP on the original file.

does this lookup succeed?
what is the value of 'nlinks' returned by the lookup? it should be 1.
if 2 is returned then something is wrong with the server.
if you do 'ls -la __file_name__' what is the value of the links field?

> On servers that pass the test the client uses a GETATTR call after
> the REMOVE-ACCESS calls.
> Can anyone tell me how the client determines which one to use? If
> not can you tell me where else I can post the question.

the client can decide to do either lookup (because it knows the name
of the file) or getattr (because it has its file handle). both
commands return the file attributes (lookup also returns the file
handle).

what versions of nfs did you use? v2 or v3?


saul

thanks for the reply Saul,

I am running the connect-a-thon tests from a client using Redhat 8
with the latest NFS patches to three different vendors NFS servers
products. It uses V3 to all servers. It is during test7 'link and
rename' that I am seeing this. To most NFS servers when the 'unlink'
is done it will be followed by an ACCESS call and then a LOOKUP call.
To one NFS server the ACCESS call is followed by a GETATTR instead.
This is consistent throughout the test as seen in a network trace. My
question is why the client would treat that Server differently? Here
is the code from test7:
************
if (unlink(new) < 0) {
error("can't unlink %s", new);
exit(1);
}
if (stat(str, &statb) < 0) {
error("can't stat %s after unlink %s",
str, new);
exit(1);
}
if (statb.st_nlink != 1) {
error("%s has %d links after unlink
(expect 1)",
str, statb.st_nlink);
exit(1);
}
********************

The client is doing a "stat" and I don't undertand why this would
generate GETATTR calls instead of LOOKUP to this specific product. All
mount options are consistent. Two of the products (one LOOKUP and the
GETATTR one) run on the same OS so the same server resource is used to
keep everything consistent. Any infomation is appreciated.

Patch


stamari@bigfoot.com (Saul) wrote in message news:<62ce112c.0308141046.2a8eaa0b@posting.google.com>...
> patchshaffer@msn.com (Patch) wrote in message
> [snip]
> > It states that the number of links is 2 instead of 1 that is expected.
> > This happens after the LINK-REMOVE portion and then it checks the number
> > of links. In looking at traces to the server that fails the client after
> > the REMOVE does a ACCESS call to the directory checking permissions and then
> > does a LOOKUP on the original file.
>
> does this lookup succeed?
> what is the value of 'nlinks' returned by the lookup? it should be 1.
> if 2 is returned then something is wrong with the server.
> if you do 'ls -la __file_name__' what is the value of the links field?
>
> > On servers that pass the test the client uses a GETATTR call after
> > the REMOVE-ACCESS calls.
> > Can anyone tell me how the client determines which one to use? If
> > not can you tell me where else I can post the question.
>
> the client can decide to do either lookup (because it knows the name
> of the file) or getattr (because it has its file handle). both
> commands return the file attributes (lookup also returns the file
> handle).
>
> what versions of nfs did you use? v2 or v3?
>
>
> saul

patchshaffer@msn.com (Patch) wrote in message

[snip]
> To most NFS servers when the 'unlink'
> is done it will be followed by an ACCESS call and then a LOOKUP call.
> To one NFS server the ACCESS call is followed by a GETATTR instead.
> This is consistent throughout the test as seen in a network trace. My
> question is why the client would treat that Server differently?
[snip]

i don't think that client is to blame. the server probably tells it
something in one of the previous replies (probably the response from
REMOVE).
i the server replies with an error or a wrong number of nlinks.

saul