<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    Let's look with wireshark:<br>
    <br>
    <tt><b>Remote Procedure Call, Type:Call XID:0x47349477</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Program: MOUNT (100005)</tt><tt><br>
    </tt><tt>Mount Service</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: MNT (1)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Path: /gv0/fleming3/db0/ALTUS_data</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Reply XID:0x47349477</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Reply State: accepted (0)</tt><tt><br>
    </tt><tt>Mount Service</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: MNT (1)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Status: OK (0)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; fhandle</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length: 34</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [hash (CRC-32): 0x10650fe6]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filehandle:
      3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Call XID:0x47349478</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Program: NFS (100003)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Program Version: 3</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Procedure: FSINFO (19)</tt><tt><br>
    </tt><tt>Network File System, FSINFO Call DH:0x10650fe6</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: FSINFO (19)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; object</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length: 34</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [hash (CRC-32): 0x10650fe6]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filehandle:
      3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Reply XID:0x47349478</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Reply State: accepted (0)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Accept State: procedure can't decode params (4)</tt><br>
    <br>
    ARGH. Not sure what's going on here - wireshark is perfectly happy
    to decode those params.<br>
    <br>
    If I do a regular filesystem mount from Linux, the result is:<br>
    <br>
    <tt><b>Remote Procedure Call, Type:Call XID:0x266eda62</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Program: MOUNT (100005)</tt><tt><br>
    </tt><tt>Mount Service</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: MNT (1)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Path: /gv0/fleming1/db0/ALTUS_data</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Reply XID:0x266eda62</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Reply State: accepted (0)</tt><tt><br>
    </tt><tt>Mount Service</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: MNT (1)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Status: OK (0)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; fhandle</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length: 34</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [hash (CRC-32): 0xb2ae682f]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filehandle:
      3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Call XID:0x68b3c756</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Program: NFS (100003)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Procedure: FSINFO (19)</tt><tt><br>
    </tt><tt>Network File System, FSINFO Call DH:0xb2ae682f</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: FSINFO (19)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; object</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length: 34</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [hash (CRC-32): 0xb2ae682f]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; filehandle:
      3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035</tt><tt><br>
    </tt><tt><b>Remote Procedure Call, Type:Reply XID:0x68b3c756</b></tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Reply State: accepted (0)</tt><tt><br>
    </tt><tt>Network File System, FSINFO Reply</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [Program Version: 3]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; [V3 Procedure: FSINFO (19)]</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Status: NFS3_OK (0)</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; obj_attributes&nbsp; Directory mode:0755 uid:500 gid:1000</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; rtmax: 65536</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; rtpref: 65536</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; rtmult: 4096</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; wtmax: 65536</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; wtpref: 65536</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; wtmult: 4096</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; dtpref: 65536</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; maxfilesize: 1125899906842624</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; time delta: 1.000000000 seconds</tt><tt><br>
    </tt><tt>&nbsp;&nbsp;&nbsp; Properties: 0x0000001b</tt><br>
    <br>
    So for some reason, gluster is happy with Linux's request but not
    Oracle's.<br>
    <br>
    All I get out of gluster is:<br>
    <tt>[2013-04-08 12:54:32.206312] E [nfs3.c:4741:nfs3svc_fsinfo]
      0-nfs-nfsv3: Error decoding arguments</tt><br>
    <br>
    <br>
    I've attached abridged packet captures and text explanations of the
    packets (thanks to wireshark).<br>
    <br>
    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?<br>
    <br>
    This is the same setup on which I reported the NFS race condition
    bug. It does have that patch applied.<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://lists.gnu.org/archive/html/gluster-devel/2013-04/msg00014.html"><font color="red"><b>MailScanner has detected a possible fraud attempt from "lists.gnu.org" claiming to be</b></font> Details:
http://lists.gnu.org/archive/html/gluster-devel/2013-04/msg00014.html</a><br>
    <br>
    Thanks,<br>
    <br>
    Michael<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
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
&#9742;: +1 519 883 1172 x5106    | termination of their C programs.' - Firth
</pre>
  </body>
</html>