NFS V4 READ файла возвращает 0 байтов - PullRequest
Новая
       35

NFS V4 READ файла возвращает 0 байтов

0 голосов
/ 29 октября 2018

Я нахожусь в процессе написания клиента NFS V4 и отлаживаю результаты с помощью Wireshark. Я не могу прочитать файл.

Через OPEN, за которым следует GETATTR, я открыл файл и подтвердил, что это нужный файл соответствующей длины (1001 байт).

Затем я пытаюсь READ один байт файла со смещением 0 и длиной 1. Полученный ответ возвращает 0 байтов данных, даже если EOF имеет значение false. Повторные вызовы команды чтения дают тот же результат.

Есть ли параметры в открытом или прочитанном виде, которые мне не хватает, чтобы фактически прочитать файл?

Wireshark Output

Открытый звонок 

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>

1 Ответ

0 голосов
/ 08 ноября 2018

Для тех, кто сталкивался с подобной ситуацией, я смог решить проблему, изменив кеш-флаг в операции SEQUENCE вызова READ с 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 , но в информацию не входит, почему это произошло.

Одна из возможностей состоит в том, что реализация спецификации NFS в Amazon имеет ошибку в поведении с sa_cachethis.

...