1

我正在编写 NFS V4 客户端，并正在使用 Wireshark 调试结果。我无法读取文件。

通过OPEN后跟GETATTR，我打开了文件并通过匹配长度（1001 字节）确认它是所需的文件。

然后，我尝试READ使用偏移量为 0 和长度为 1 的文件的单个字节。即使 EOF 为假，结果回复也会返回 0 字节的数据。重复调用 read 命令会产生相同的结果。

open 或 read 中是否有我在实际读取文件时缺少的参数？

Wireshark 输出

公开电话

Operations (count: 5): SEQUENCE, PUTROOTFH, OPEN, GETFH, GETATTR
    Opcode: SEQUENCE (53)
    Opcode: PUTROOTFH (24)
    Opcode: OPEN (18)
        seqid: 0x00000000
        share_access: OPEN4_SHARE_ACCESS_READ (1)
        share_deny: OPEN4_SHARE_DENY_NONE (0)
        clientid: 0x13f5c375a578cd7c
        owner: <DATA>
        Open Type: OPEN4_NOCREATE (0)
        Claim Type: CLAIM_NULL (0)
    Opcode: GETFH (10)
    Opcode: GETATTR (9)

打开回复

Operations (count: 5)
    Opcode: SEQUENCE (53)
    Opcode: PUTROOTFH (24)
    Opcode: OPEN (18)
        Status: NFS4_OK (0)
        StateID
            [StateID Hash: 0x91a9]
            StateID seqid: 1
            StateID Other: 13f5c375a578cd7c00000000
            [StateID Other hash: 0x5b73]
        change_info
            Atomic: Yes
            changeid (before): 110
            changeid (after): 110
        result flags: 0x00000004, locktype posix
            .... .... .... .... .... .... .... ..0. = confirm: False
            .... .... .... .... .... .... .... .1.. = locktype posix: True
            .... .... .... .... .... .... .... 0... = preserve unlinked: False
            .... .... .... .... .... .... ..0. .... = may notify lock: False
        Delegation Type: OPEN_DELEGATE_NONE (0)
    Opcode: GETFH (10)
        Status: NFS4_OK (0)
        Filehandle
            length: 128
            [hash (CRC-32): 0xc5dcd623]
            FileHandle: 2b3e5cee938ee2b6afff448601a384b8ffc30bab28b5e2a4...
    Opcode: GETATTR (9)
        Status: NFS4_OK (0)
        Attr mask: 0x00000010 (Size)
            reqd_attr: Size (4)
                size: 1001

阅读电话

Operations (count: 3): SEQUENCE, PUTFH, READ
    Opcode: SEQUENCE (53)
    Opcode: PUTFH (22)
        FileHandle
            length: 128
            [hash (CRC-32): 0xc5dcd623]
            FileHandle: 2b3e5cee938ee2b6afff448601a384b8ffc30bab28b5e2a4...
    Opcode: READ (25)
        StateID
            [StateID Hash: 0x91a9]
            StateID seqid: 1
            StateID Other: 13f5c375a578cd7c00000000
            [StateID Other hash: 0x5b73]
        offset: 0
        count: 1

阅读回复

Operations (count: 3)
    Opcode: SEQUENCE (53)
    Opcode: PUTFH (22)
        Status: NFS4_OK (0)
    Opcode: READ (25)
        Status: NFS4_OK (0)
        eof: 0
        Read length: 0
        Data: <EMPTY>
4

1 回答 1

0

For anybody who runs into a similar situation, I was able to fix the problem by changing the cachethis flag in the SEQUENCE operation of the READ call from true to false.

   struct SEQUENCE4args {
           sessionid4     sa_sessionid;
           sequenceid4    sa_sequenceid;
           slotid4        sa_slotid;
           slotid4        sa_highest_slotid;
           bool           sa_cachethis; // ensure this is false
   };

Some of the behavior of the cachethis flag is described in RFC 5661, but the information does not include why this behavior occurred.

One possibility is that Amazon's implementation of the NFS spec has a bug in the behavior with sa_cachethis.

于 2018-11-07T21:03:19.113 回答