Bug 497430 - GFS2 does not work with NFS v2
Summary: GFS2 does not work with NFS v2
Keywords:
Status: CLOSED DUPLICATE of bug 497954
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.3
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
: ---
Assignee: Steve Whitehouse
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-23 20:55 UTC by Craig
Modified: 2009-04-29 08:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 08:35:07 UTC
Target Upstream Version:
Embargoed:


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

Description Craig 2009-04-23 20:55:19 UTC
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 08:35:07 UTC
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.