|
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
