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.