On Apr 8, 2009 8:23am, Steven Whitehouse <swhiteho@redhat.com> wrote:<br />> Hi,<br />> <br />> <br />> <br />> On Wed, 2009-04-08 at 08:16 -0700, Craig Johnston wrote:<br />> <br />> > On Wed, Apr 8, 2009 at 1:54 AM, Steven Whitehouse swhiteho@redhat.com> wrote:<br />> <br />> > ><br />> <br />> > > Hi,<br />> <br />> > ><br />> <br />> > > On Tue, 2009-04-07 at 13:04 -0700, Craig Johnston wrote:<br />> <br />> > > > We have found that NFS version 2 does not seem to be compatible with<br />> <br />> > > > an NFS exported GFS2 file system.  The NFS client can mount the file<br />> <br />> > > > system, but any file I/O results in Stale File Handle and I/O errors.<br />> <br />> > > ><br />> <br />> > > > It looks very much like the problem described here -<br />> <br />> > > > https://bugzilla.redhat.com/show_bug.cgi?id=229345<br />> <br />> > > ><br />> <br />> > > > Has there been any progress on resolving this issue, or are we out of<br />> <br />> > > > luck.  We have a legacy device that will only use NFS v2, and we would<br />> <br />> > > > very much like to use GFS2 as we do for the rest of our system.<br />> <br />> > > ><br />> <br />> > > > To replicate the problem for a GFS2 exported file system (say<br />> <br />> > > > /data/mygfs2_fs on host foo ), mount it on another host as<br />> <br />> > > > "% mount -o nfsvers=2 foo:/data/mygfs2_fs /mnt/tmp"<br />> <br />> > > ><br />> <br />> > > > You will find that you can list the directory entries, but any attempt<br />> <br />> > > > to read or write to files will fail.<br />> <br />> > > ><br />> <br />> > > > Note, we find that the GFS file system does not seem to have problems<br />> <br />> > > > with NFS v2 clients, only GFS2.<br />> <br />> > > ><br />> <br />> > > > Any help would be appreciated.<br />> <br />> > > > Craig<br />> <br />> > > ><br />> <br />> > > Yes, it is a bug inherited from GFS. GFS2 uses the same filehandles<br />> <br />> > > (i.e. too large for NFSv2) so that for the time being, only NFSv3+ will<br />> <br />> > > work with GFS2. I don't know why GFS appears to work and GFS2 doesn't -<br />> <br />> > > they should be identical in that respect,<br />> <br />> > ><br />> <br />> > > Steve.<br />> <br />> > ><br />> <br />> > ><br />> <br />> > Bummer.  This is a capability we we really need, as we have to<br />> <br />> > interface with some older systems running VxWorks that only supports<br />> <br />> > NFS v2.  We have verified that GFS supports NFS v2.  Does this mean<br />> <br />> > there is hope that GFS2 could also support NFS v2 since they use the<br />> <br />> > same filehandles?  Where should I start poking around if I wanted to<br />> <br />> > delve into the source?<br />> <br />> ><br />> <br />> > Thanks,<br />> <br />> > Craig<br />> <br />> <br />> <br />> By all means have a look in the source. I suspect that there would be<br />> <br />> issues if you ever had a filesystem larger than 2^32 blocks with GFS<br />> <br />> using the NFSv2 handles. It might just be silently ignoring that issue,<br />> <br />> so I'd be careful.<br />> <br />> <br />> <br />> I would like to see NFSv2 working with GFS2, so I'd be happy to accept<br />> <br />> patches if you can work out how to stuff all the required information<br />> <br />> into such a small file handle. Also it would need to leave the existing<br />> <br />> file handles for NFSv3 alone as we must not change that format in an<br />> <br />> incompatible way.<br />> <br />> <br />> <br />> All the code is easy to find in ops_export.c and its all self-contained<br />> <br />> in that file,<br />> <br />> <br />> <br />> Steve.<br />> <br />> <br />> <br />> <br />> <br /><br />Well, we found a fix that works for us.  To be specific, we are working with GFS2 in RHEL5.3.<br /><br />Inspecting ops_export.c for GFS2, and comparing that to the implementation in GFS, we discovered that gfs2_decode_fh() is using fh_len rather than fh_type.  Per the published API, fh_len does not necessarily tell the whole story, as it is the maximum size not necessarily the actual size of the file handle.  For NFSv2 the encoded file handle is of type GFS2_SMALL_FH_SIZE, but this was being ignored in the decode method.  The following patch has been tested extensively in our mixed NFSv3 & NFSv2 environment without any trouble.<br /><br />----------------------------------------------------------------------------------------------------------------------<br />diff -up linux-2.6.18.i686/fs/gfs2/ops_export.c.gfs2-nfs2 linux-2.6.18.i686/fs/gfs2/ops_export.c<br />--- linux-2.6.18.i686/fs/gfs2/ops_export.c.gfs2-nfs2    2009-04-16 09:57:19.000000000 -0700<br />+++ linux-2.6.18.i686/fs/gfs2/ops_export.c      2009-04-16 10:02:02.000000000 -0700<br />@@ -42,7 +42,7 @@ static struct dentry *gfs2_decode_fh(str<br /><br />        memset(&parent, 0, sizeof(struct gfs2_inum));<br /><br />-       switch (fh_len) {<br />+       switch (fh_type) {<br />        case GFS2_LARGE_FH_SIZE:<br />                parent.no_formal_ino = ((u64)be32_to_cpu(fh[4])) << 32;<br />                parent.no_formal_ino |= be32_to_cpu(fh[5]);<br />----------------------------------------------------------------------------------------------------------------------<br /><br />Craig