NFS/RPC on Linux - Where does it sleep ? - NFS

This is a discussion on NFS/RPC on Linux - Where does it sleep ? - NFS ; I'm working on RedHat Linux, 2.4.20 kernel. I'm trying to understand where the read operation on NFS sleeps while waiting for the results of the read. The caller goes to sys_read(), then eventually to nfs_readpage_async(), then eventually to nfs_list_add_request(). But ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: NFS/RPC on Linux - Where does it sleep ?

  1. NFS/RPC on Linux - Where does it sleep ?

    I'm working on RedHat Linux, 2.4.20 kernel.
    I'm trying to understand where the read operation on NFS sleeps
    while waiting for the results of the read.

    The caller goes to sys_read(), then eventually to nfs_readpage_async(),
    then eventually to nfs_list_add_request(). But I can't make out where
    it sleeps while the request is going on. struct rpc_task has a field
    called tk_exit which points to the callback routine which is
    nfs_readpage_result(). Where does the read operation sleep in NFS ?

    On the other side of the operation, when the request comes in from the network,
    the packet makes its way from the NIC driver, to IP, to UDP, then at
    some point, it ends up in the callback routine. However I don't see
    a "wake". Where should it be ?

    My bigger goal is to catch the read buffer and see what NFS is receiving.
    I know that the result of my read request comes in as three packets.
    So I'm trying to see what those packets look like when NFS receives them.
    The bug I'm trying to track down is a corruption in one of those packets.
    AFAIK, the packets are clean on the wire. I'm using the ethereal tool.

    If you can tell me where the NFS read operation sleeps & gets woken up,
    perhaps I can look at the read buffer at that point. If you need more
    info, pls let me know.

    thank you

  2. Re: NFS/RPC on Linux - Where does it sleep ?

    google wrote:

    > I'm working on RedHat Linux, 2.4.20 kernel.
    > I'm trying to understand where the read operation on NFS sleeps
    > while waiting for the results of the read.


    (snip)

    As far as I ever knew about Sun's implementations it
    slept in the same place it did for real disks.

    > My bigger goal is to catch the read buffer and see what NFS is receiving.
    > I know that the result of my read request comes in as three packets.
    > So I'm trying to see what those packets look like when NFS receives them.
    > The bug I'm trying to track down is a corruption in one of those packets.
    > AFAIK, the packets are clean on the wire. I'm using the ethereal tool.


    I presume you mean fragments of a 4K UDP packet. IP should
    reassemble them before passing them onto any higher layer.
    For TCP, it is TCP's responsibility to deliver a reliable
    stream of bytes.

    Be sure that UDP checksum is turned on. It was popular for
    many years to turn it off to improve NFS, assuming it was only
    over a CRC protected ethernet.

    -- glen


+ Reply to Thread