Bug 497430 - GFS2 does not work with NFS v2
GFS2 does not work with NFS v2
Status: CLOSED DUPLICATE of bug 497954
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
i386 Linux
low Severity high
: ---
: ---
Assigned To: Steve Whitehouse
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-23 16:55 EDT by Craig
Modified: 2009-04-29 04:35 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 04:35:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch file to fix NFSv2 exports of GFS2 file systems (550 bytes, patch)
2009-04-23 16:55 EDT, Craig
no flags Details | Diff

  None (edit)
Description Craig 2009-04-23 16:55:19 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):

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.
Comment 1 Steve Whitehouse 2009-04-29 04:35:07 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.