Created attachment 341011 [details] Patch file to fix NFSv2 exports of GFS2 file systems Description of problem: We are exporting a GFS2 file system via NFS. We have found that NFS clients that use version 2 of the NFS protocol can not read or write files to the mounted file system. Any attempts return Stale Handle or I/O errors. Version-Release number of selected component (if applicable): RHEL 5.3 How reproducible: Always Steps to Reproduce: The GFS2 file system is mounted on host "blade1" is as follows, root@blade1:/root> mount | grep shared_fs1 /dev/sde on /mnt/mutable/shared_fs1 type gfs2 (rw,nosuid,noexec,noatime,hostdata=jid=1:id=327685:first=0) This mount point is then exported via cluster management with the result as follows root@blade1:/root> exportfs -v /mnt/mutable/shared_fs1 172.10.0.0/16(rw,async,wdelay,root_squash,no_subtree_check,fsid=103,anonuid=65534,anongid=65534) Then on another host (client1), the NFS exported file system is mounted using NFS version 2 as follows, root@client1:/root> mount -o nfsvers=2 blade1:/mnt/mutable/shared_fs1 /mnt/tmp root@client1:/root> cat /proc/mounts | grep shared_fs1 blade1:/mnt/mutable/shared_fs1 /mnt/tmp nfs rw,vers=2,rsize=8192,wsize=8192,hard,proto=udp,timeo=11,retrans=2,sec=sys,addr=blade1 0 0 A directory listing works fine, root@client1:/root> ls -l /mnt/tmp total 72 -r--r--r-- 1 user user 67204 Apr 2 23:35 CommPlan.txt but any attempt to read or write fails, root@client1:/root> cat /mnt/tmp/CommPlan.txt cat: /mnt/tmp/CommPlan.txt: Input/output error root@client1:/root> echo hello > /mnt/tmp/junk -bash: /mnt/tmp/junk: Stale NFS file handle Actual results: NFS I/O fails Expected results: NFS I/O works :) Additional info: This probably the same problem reported in bugzilla #229345, but the patch that was incorporated was incorrect. A patch against the current Red Hat kernel to fix this problem (at least for us) is attached. Found the reason that NFS v2 exports don't work w/ GFS2. The file linux/Documentation/filesystems/Exporting says the following in it's last paragraph: A filehandle fragment consists of an array of 1 or more 4byte words, together with a one byte "type". The decode_fh routine should not depend on the stated size that is passed to it. This size may be larger than the original filehandle generated by encode_fh, in which case it will have been padded with nuls. Rather, the encode_fh routine should choose a "type" which indicates the decode_fh how much of the filehandle is valid, and how it should be interpreted. ------------ In ops_export.c function gfs2_decode_fh, the parameter fh_len was being used instead of fh_type. The implementation for GFS1 used fh_type, so it worked correctly. This is the reason GFS2 was incompatible w/ NFSv2. We have tested it in several scenarios and it works well for us.
We seem to have two bugs open for this, so I'm marking this one as a dup of the other. *** This bug has been marked as a duplicate of bug 497954 ***