Question

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

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

然后我尝试READ偏移0和长度1的文件的单个字节。即使EOF为false，返回的结果也返回0字节的数据。重复调用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>

Answer 1

对于遇到类似情况的任何人，我都可以通过将READ调用的SEQUENCE操作中的cachethis标志从true更改为false来解决此问题。

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

RFC 5661中描述了cachethis标志的某些行为，但是该信息不包括发生此行为的原因。

一种可能性是，亚马逊对NFS规范的实施在sa_cachethis的行为中存在错误。

NFS V4读取文件返回0字节

1 个答案: