Redhat 8 NFS does a Lookup instead of Getattr - NFS

This is a discussion on Redhat 8 NFS does a Lookup instead of Getattr - NFS ; I have a situation where using a redhat client and using the connect-a-thon tests fails during test7. It states that the number of links is 2 instead of 1 that is expected. This happens after the LINK-REMOVE portion and then ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Redhat 8 NFS does a Lookup instead of Getattr

  1. Redhat 8 NFS does a Lookup instead of Getattr

    I have a situation where using a redhat client and using the
    connect-a-thon tests fails during test7. 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.
    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.

    Thanks,
    Patch

  2. Re: Redhat 8 NFS does a Lookup instead of Getattr

    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

  3. Re: Redhat 8 NFS does a Lookup instead of Getattr

    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


  4. Re: Redhat 8 NFS does a Lookup instead of Getattr

    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

+ Reply to Thread