Red Hat Bugzilla – Bug 497430
GFS2 does not work with NFS v2
Last modified: 2009-04-29 04:35:07 EDT
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):
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
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
-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
NFS I/O fails
NFS I/O works :)
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 ***