Bug 1132392

+++ This bug was initially created as a clone of Bug #1130969 +++
+++                                                           +++
+++ This bug is for backporting the fix to glusterfs-3.4      +++
+++                                                           +++

Description of problem (from Emmanuel Dreyfus):

NFS READDIR replies ar e made of a header, a sequence of
entriers, and a EOF flag. When GlusterFS's NFS server is
used along with stripe xlator, it fails to set the EOF
flag, which violates NFS RFC and confuses some clients.

The bug is caused because nfs xlator sets EOF if it gets
op_errno set to ENOENT. That value is produced in storage
xlator and propagated through server, client, and other
xlators until stripe xlator handles it. stripe only passed
op_errno if op_ret < 0, which is not the case here.

--- Additional comment from Niels de Vos on 2014-08-18 14:01:37 CEST ---

Example of missing EOF after the "Value Follows: No" marker.

    Frame 834: 1356 bytes on wire (10848 bits), 1356 bytes captured (10848 bits)
    Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Remote Procedure Call, Type:Reply XID:0xe8e42eee
    Network File System, READDIRPLUS Reply
        [Program Version: 3]
        [V3 Procedure: READDIRPLUS (17)]
        Status: NFS3_OK (0)
        dir_attributes  Directory mode: 0755 uid: 0 gid: 0
            ...
        Verifier: Opaque Data
        Value Follows: Yes
        Entry: name e246f09c-2f58-417b-8c3e-6f7f5307154f
        ...
        Value Follows: Yes
        Entry: name 17cec36b-c553-47bc-a7da-4663f3efbac2
            ...
        Value Follows: No
        EOF: 0

--- Additional comment from Anand Avati on 2014-08-18 14:44:55 CEST ---

REVIEW: http://review.gluster.org/8493 (NFS: stripe-xlator should pass EOF at end of READDIR) posted (#3) for review on master by Niels de Vos (ndevos)

--- Additional comment from Niels de Vos on 2014-08-18 14:47:31 CEST ---

Confirmation that EOF is set with the patch:

    Frame 654: 1356 bytes on wire (10848 bits), 1356 bytes captured (10848 bits)
    Internet Protocol Version 4, Src: 127.0.0.1 (127.0.0.1), Dst: 127.0.0.1 (127.0.0.1)
    Transmission Control Protocol, Src Port: nfs (2049), Dst Port: accessnetwork (699), Seq: 19741, Ack: 1777, Len: 1288
    Remote Procedure Call, Type:Reply XID:0xa604116c
    Network File System, READDIRPLUS Reply
        [Program Version: 3]
        [V3 Procedure: READDIRPLUS (17)]
        Status: NFS3_OK (0)
        dir_attributes  Directory mode: 0755 uid: 0 gid: 0
            ...
        Entry: name e246f09c-2f58-417b-8c3e-6f7f5307154f
        ...
        Value Follows: Yes
        Entry: name 17cec36b-c553-47bc-a7da-4663f3efbac2
            ...
        Value Follows: No
        EOF: 1

--- Additional comment from Anand Avati on 2014-08-19 14:23:25 CEST ---

COMMIT: http://review.gluster.org/8493 committed in master by Niels de Vos (ndevos) 
------
commit 9b5231e5c98b8cfa116838287c7a14042702795f
Author: Niels de Vos <ndevos>
Date:   Mon Aug 18 12:11:35 2014 +0200

    NFS: stripe-xlator should pass EOF at end of READDIR
    
    NFS READDIR replies are made of a header, a sequence of
    entries, and a EOF flag. When GlusterFS's NFS server is
    used along with stripe xlator, it fails to set the EOF
    flag, which violates NFS RFC and confuses some clients.
    
    The bug is caused because nfs xlator sets EOF if it gets
    op_errno set to ENOENT. That value is produced in storage
    xlator and propagated through server, client, and other
    xlators until stripe xlator handles it. stripe only passed
    op_errno if op_ret < 0, which is not the case here. This
    change set adds a special case for that situation to fix
    the problem.
    
    Change-Id: Ie6db94b0515292387cfb04c1e4a9363f34fcd19a
    BUG: 1130969
    Reported-by: Emmanuel Dreyfus <manu>
    Signed-off-by: Niels de Vos <ndevos>
    Reviewed-on: http://review.gluster.org/8493
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Santosh Pradhan <spradhan>
    Reviewed-by: Kaleb KEITHLEY <kkeithle>
    Reviewed-by: Emmanuel Dreyfus <manu>
    Tested-by: Emmanuel Dreyfus <manu>