gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Brown
Subject: [Gluster-devel] gluster doesn't like Oracle's FSINFO RPC call
Date: Mon, 08 Apr 2013 13:57:55 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4

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.
MailScanner has detected a possible fraud attempt from "lists.gnu.org" claiming to be 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

Attachment: LinuxGoodNFSCalls.pcap
Description: application/vnd.tcpdump.pcap

Attachment: OracleBadNFSCall.pcap
Description: application/vnd.tcpdump.pcap

Attachment: OracleBadNFSCall.txt.xz
Description: application/xz

Attachment: LinuxGoodNFSCalls.txt.xz
Description: application/xz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]