<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> Program: MOUNT (100005)</tt><tt><br>
</tt><tt>Mount Service</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: MNT (1)]</tt><tt><br>
</tt><tt> 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> Reply State: accepted (0)</tt><tt><br>
</tt><tt>Mount Service</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: MNT (1)]</tt><tt><br>
</tt><tt> Status: OK (0)</tt><tt><br>
</tt><tt> fhandle</tt><tt><br>
</tt><tt> length: 34</tt><tt><br>
</tt><tt> [hash (CRC-32): 0x10650fe6]</tt><tt><br>
</tt><tt> [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]</tt><tt><br>
</tt><tt> filehandle:
3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5</tt><tt><br>
</tt><tt><b>Remote Procedure Call, Type:Call XID:0x47349478</b></tt><tt><br>
</tt><tt> Program: NFS (100003)</tt><tt><br>
</tt><tt> Program Version: 3</tt><tt><br>
</tt><tt> Procedure: FSINFO (19)</tt><tt><br>
</tt><tt>Network File System, FSINFO Call DH:0x10650fe6</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: FSINFO (19)]</tt><tt><br>
</tt><tt> object</tt><tt><br>
</tt><tt> length: 34</tt><tt><br>
</tt><tt> [hash (CRC-32): 0x10650fe6]</tt><tt><br>
</tt><tt> [Name: 192.168.10.1:/gv0/fleming3/db0/ALTUS_data]</tt><tt><br>
</tt><tt> filehandle:
3a4f20117b487f884f169490a0349afacf71331965f573144e93b289a395148edfe5</tt><tt><br>
</tt><tt><b>Remote Procedure Call, Type:Reply XID:0x47349478</b></tt><tt><br>
</tt><tt> Reply State: accepted (0)</tt><tt><br>
</tt><tt> 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> Program: MOUNT (100005)</tt><tt><br>
</tt><tt>Mount Service</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: MNT (1)]</tt><tt><br>
</tt><tt> 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> Reply State: accepted (0)</tt><tt><br>
</tt><tt>Mount Service</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: MNT (1)]</tt><tt><br>
</tt><tt> Status: OK (0)</tt><tt><br>
</tt><tt> fhandle</tt><tt><br>
</tt><tt> length: 34</tt><tt><br>
</tt><tt> [hash (CRC-32): 0xb2ae682f]</tt><tt><br>
</tt><tt> [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]</tt><tt><br>
</tt><tt> filehandle:
3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035</tt><tt><br>
</tt><tt><b>Remote Procedure Call, Type:Call XID:0x68b3c756</b></tt><tt><br>
</tt><tt> Program: NFS (100003)</tt><tt><br>
</tt><tt> Procedure: FSINFO (19)</tt><tt><br>
</tt><tt>Network File System, FSINFO Call DH:0xb2ae682f</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: FSINFO (19)]</tt><tt><br>
</tt><tt> object</tt><tt><br>
</tt><tt> length: 34</tt><tt><br>
</tt><tt> [hash (CRC-32): 0xb2ae682f]</tt><tt><br>
</tt><tt> [Name: 192.168.10.1:/gv0/fleming1/db0/ALTUS_data]</tt><tt><br>
</tt><tt> filehandle:
3a4f20117b487f884f169490a0349afacf71e8bd0e2198c34cb88a0231dbeb071035</tt><tt><br>
</tt><tt><b>Remote Procedure Call, Type:Reply XID:0x68b3c756</b></tt><tt><br>
</tt><tt> Reply State: accepted (0)</tt><tt><br>
</tt><tt>Network File System, FSINFO Reply</tt><tt><br>
</tt><tt> [Program Version: 3]</tt><tt><br>
</tt><tt> [V3 Procedure: FSINFO (19)]</tt><tt><br>
</tt><tt> Status: NFS3_OK (0)</tt><tt><br>
</tt><tt> obj_attributes Directory mode:0755 uid:500 gid:1000</tt><tt><br>
</tt><tt> rtmax: 65536</tt><tt><br>
</tt><tt> rtpref: 65536</tt><tt><br>
</tt><tt> rtmult: 4096</tt><tt><br>
</tt><tt> wtmax: 65536</tt><tt><br>
</tt><tt> wtpref: 65536</tt><tt><br>
</tt><tt> wtmult: 4096</tt><tt><br>
</tt><tt> dtpref: 65536</tt><tt><br>
</tt><tt> maxfilesize: 1125899906842624</tt><tt><br>
</tt><tt> time delta: 1.000000000 seconds</tt><tt><br>
</tt><tt> 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
☎: +1 519 883 1172 x5106 | termination of their C programs.' - Firth
</pre>
</body>
</html>