[Gluster-devel] gluster doesn't like Oracle's FSINFO RPC call

[Michael Brown]

I'm trying to get Oracle's DNFS working against gluster's internal NFS
and I've run into a snag. After Oracle mounts the exported NFS
filesystem the FSINFO call fails.

Let's look with wireshark:

*Remote Procedure Call, Type:Call XID:0x47349477*
    Program: MOUNT (100005)
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Path: /gv0/fleming3/db0/ALTUS_data
*Remote Procedure Call, Type:Reply XID:0x47349477*
    Reply State: accepted (0)
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Status: OK (0)
    fhandle
        length: 34
        [hash (CRC-32): 0x10650fe6]
        [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]
        filehandle:
3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5
*Remote Procedure Call, Type:Call XID:0x47349478*
    Program: NFS (100003)
    Program Version: 3
    Procedure: FSINFO (19)
Network File System, FSINFO Call DH:0x10650fe6
    [Program Version: 3]
    [V3 Procedure: FSINFO (19)]
    object
        length: 34
        [hash (CRC-32): 0x10650fe6]
        [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]
        filehandle:
3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5
*Remote Procedure Call, Type:Reply XID:0x47349478*
    Reply State: accepted (0)
    Accept State: procedure can't decode params (4)

ARGH. Not sure what's going on here - wireshark is perfectly happy to
decode those params.

If I do a regular filesystem mount from Linux, the result is:

*Remote Procedure Call, Type:Call XID:0x266eda62*
    Program: MOUNT (100005)
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Path: /gv0/fleming1/db0/ALTUS_data
*Remote Procedure Call, Type:Reply XID:0x266eda62*
    Reply State: accepted (0)
Mount Service
    [Program Version: 3]
    [V3 Procedure: MNT (1)]
    Status: OK (0)
    fhandle
        length: 34
        [hash (CRC-32): 0xb2ae682f]
        [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]
        filehandle:
3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035
*Remote Procedure Call, Type:Call XID:0x68b3c756*
    Program: NFS (100003)
    Procedure: FSINFO (19)
Network File System, FSINFO Call DH:0xb2ae682f
    [Program Version: 3]
    [V3 Procedure: FSINFO (19)]
    object
        length: 34
        [hash (CRC-32): 0xb2ae682f]
        [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]
        filehandle:
3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035
*Remote Procedure Call, Type:Reply XID:0x68b3c756*
    Reply State: accepted (0)
Network File System, FSINFO Reply
    [Program Version: 3]
    [V3 Procedure: FSINFO (19)]
    Status: NFS3_OK (0)
    obj_attributes  Directory mode:0755 uid:500 gid:1000
    rtmax: 65536
    rtpref: 65536
    rtmult: 4096
    wtmax: 65536
    wtpref: 65536
    wtmult: 4096
    dtpref: 65536
    maxfilesize: 1125899906842624
    time delta: 1.000000000 seconds
    Properties: 0x0000001b

So for some reason, gluster is happy with Linux's request but not Oracle's.

All I get out of gluster is:
[2013-04-08 12:54:32.206312] E [nfs3.c:4741:nfs3svc_fsinfo] 0-nfs-nfsv3:
Error decoding arguments


I've attached abridged packet captures and text explanations of the
packets (thanks to wireshark).

Can someone please look at this and determine if it's gluster's parsing
of the RPC call to blame, or if it's Oracle?

This is the same setup on which I reported the NFS race condition bug.
It does have that patch applied.
Details:
http://lists.gnu.org/archive/html/gluster-devel/2013-04/msg00014.html

Thanks,

Michael

-- 
Michael Brown               | `One of the main causes of the fall of
Systems Consultant          | the Roman Empire was that, lacking zero,
Net Direct Inc.             | they had no way to indicate successful
?: +1 519 883 1172 x5106    | termination of their C programs.' - Firth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130408/0d22d523/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxGoodNFSCalls.pcap
Type: application/vnd.tcpdump.pcap
Size: 1636 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130408/0d22d523/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OracleBadNFSCall.pcap
Type: application/vnd.tcpdump.pcap
Size: 1010 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130408/0d22d523/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OracleBadNFSCall.txt.xz
Type: application/x-xz
Size: 1412 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130408/0d22d523/attachment-0002.xz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxGoodNFSCalls.txt.xz
Type: application/x-xz
Size: 1696 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130408/0d22d523/attachment-0003.xz>