All of lore.kernel.org
 help / color / mirror / Atom feed
* Your comments, guidance, advice please :)
@ 2012-08-13 14:55 Jim Vanns
  2012-08-13 16:40 ` Myklebust, Trond
  0 siblings, 1 reply; 5+ messages in thread
From: Jim Vanns @ 2012-08-13 14:55 UTC (permalink / raw)
  To: linux-nfs

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

Hello NFS hackers. First off, fear not - the attached patch is not
something I wish to submit to the mainline kernel! However, it is
important for me that you pass judgement or comment on it. It is small.

Basically, I've written the patch solely to workaround a Bluearc bug
where it duplicates fileids within an fsid and therefore we're not able
to rely on the fsid+fileid to identify distinct files in an NFS
filesystem. Some of our storage indexing and reporting software relies
on this and works happily with other, more RFC-adherent
implementations ;)

The functional change is one that modified the received fileid to a hash
of the file handle as that, thankfully, is still unique. As with a
fileid I need this hash to remain consistent for the lifetime of a file.
It is used as a unique identifier in a database.

I'd really appreciate it if you could let me know of any problems you
see with it - whether it'll break some client-side code, hash table use
or worse still send back bad data to the server.

I've modified what I can see as the least amount of code possible - and
my test VM is working happily as a client with this patch. It is
intended that the patch modifies only client-side code once the Bluearc
RPCs are pulled off the wire. I never want to send back these modified
fileids to the server.

Kind regards and thanks for your help, 

Jim Vanns

PS. Sorry, I should mention of course that this patch is a diff from the
2.6.32 kernel as shipped with Fedora 12 - so not a recent kernel.

-- 
Jim Vanns
Systems Programmer
Framestore

[-- Attachment #2: fscfc-nfs-fileid-hash.patch --]
[-- Type: text/x-patch, Size: 4486 bytes --]

--- linux-2.6.32/fs/nfs/inode.c.orig	2012-08-13 11:24:41.902452726 +0100
+++ linux-2.6.32/fs/nfs/inode.c	2012-08-13 12:41:38.871454124 +0100
@@ -60,6 +60,52 @@ static int nfs_update_inode(struct inode
 
 static struct kmem_cache * nfs_inode_cachep;
 
+/*
+ * FSCFC:
+ *
+ * Implementations of FNV-1 hash function:
+ * http://isthe.com/chongo/tech/comp/fnv
+ * http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash#Notes
+ */
+static inline uint32_t
+nfs_fh_hash32(struct nfs_fh *fh)
+{
+    static const uint32_t seed = 2166136261U,
+                          prime = 16777619U;
+    uint32_t hash = seed, i = 0;
+
+    while (i < fh->size) {
+        hash = (hash * prime) ^ fh->data[i];
+        ++i;
+    }
+
+    return hash;
+}
+
+static inline uint64_t
+nfs_fh_hash64(struct nfs_fh *fh)
+{
+    static const uint64_t seed = 14695981039346656037U,
+                          prime = 1099511628211U;
+    uint64_t hash = seed, i = 0;
+
+    while (i < fh->size) {
+        hash = (hash * prime) ^ fh->data[i];
+        ++i;
+    }
+
+    return hash;
+}
+
+static inline unsigned long
+nfs_fh_hash(struct nfs_fh *fh)
+{
+    if (sizeof(unsigned long) == 4)
+        return nfs_fh_hash32(fh);
+
+    return nfs_fh_hash64(fh);
+}
+
 static inline unsigned long
 nfs_fattr_to_ino_t(struct nfs_fattr *fattr)
 {
@@ -268,7 +314,28 @@ nfs_fhget(struct super_block *sb, struct
 	if ((fattr->valid & NFS_ATTR_FATTR_TYPE) == 0)
 		goto out_no_inode;
 
-	hash = nfs_fattr_to_ino_t(fattr);
+    /* 
+     * FSCFC:
+     *
+     * This patch exists solely to work around the Bluearc duplicate inode/NFS
+     * fileid bug. On Bluearc filesystems a distinct, non-hardlinked file or
+     * directory appears to share the same fsid + fileid with other completely
+     * unrelated files elsewhere in the hierarchy. This becomes a problem for
+     * any system dependent on the commonly accpepted notion of the NFSv3 fsid
+     * and fileid uniquely identifying a single file/directory within an NFS
+     * filesystem. Thankfully, the NFS file handle for any duplications are
+     * still unique :)
+     *
+     * We must update *both* the hash value (was the i_ino/fileid as returned
+     * by nfs_fattr_to_ino_t() above) and fileid here as it is used as the key
+     * in the inode cache maintained within iget5_locked() below.
+     *
+     * We set fattr->fileid to 'hash' to because NFS_FILEID and set_nfs_fileid()
+     * just copy/return 'fileid' from this structure which the server has
+     * already sent as the inode on it's filesystem as you'd expect. This is
+     * what we overwrite - client side only.
+     */
+    fattr->fileid = hash = nfs_fh_hash(fh); // JV alternate code
 
 	inode = iget5_locked(sb, hash, nfs_find_actor, nfs_init_locked, &desc);
 	if (inode == NULL) {
@@ -736,6 +803,7 @@ __nfs_revalidate_inode(struct nfs_server
 		goto out;
 	}
 
+    fattr.fileid = nfs_fh_hash(NFS_FH(inode)); // JV alternate code
 	status = nfs_refresh_inode(inode, &fattr);
 	if (status) {
 		dfprintk(PAGECACHE, "nfs_revalidate_inode: (%s/%Ld) refresh failed, error=%d\n",
@@ -903,13 +971,17 @@ static void nfs_wcc_update_inode(struct 
  */
 static int nfs_check_inode_attributes(struct inode *inode, struct nfs_fattr *fattr)
 {
+    unsigned long hash = nfs_fh_hash(NFS_FH(inode)); // JV alternate code
 	struct nfs_inode *nfsi = NFS_I(inode);
 	loff_t cur_size, new_isize;
 	unsigned long invalid = 0;
 
+    /*
+     * FSCFC: Compare against the hashed file handle, not the fileid
+     */
 
 	/* Has the inode gone and changed behind our back? */
-	if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != fattr->fileid)
+	if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != hash)
 		return -EIO;
 	if ((fattr->valid & NFS_ATTR_FATTR_TYPE) && (inode->i_mode & S_IFMT) != (fattr->mode & S_IFMT))
 		return -EIO;
@@ -1150,12 +1222,16 @@ static int nfs_update_inode(struct inode
 	unsigned long invalid = 0;
 	unsigned long now = jiffies;
 	unsigned long save_cache_validity;
+    unsigned long hash = nfs_fh_hash(NFS_FH(inode)); // JV alternate code
 
 	dfprintk(VFS, "NFS: %s(%s/%ld ct=%d info=0x%x)\n",
 			__func__, inode->i_sb->s_id, inode->i_ino,
 			atomic_read(&inode->i_count), fattr->valid);
 
-	if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != fattr->fileid)
+    /*
+     * FSCFC: Compare against the hashed file handle, not the fileid
+     */
+	if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != hash)
 		goto out_fileid;
 
 	/*

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Your comments, guidance, advice please :)
  2012-08-13 14:55 Your comments, guidance, advice please :) Jim Vanns
@ 2012-08-13 16:40 ` Myklebust, Trond
  2012-08-13 16:51   ` Jim Vanns
                     ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Myklebust, Trond @ 2012-08-13 16:40 UTC (permalink / raw)
  To: Jim Vanns; +Cc: linux-nfs

T24gTW9uLCAyMDEyLTA4LTEzIGF0IDE1OjU1ICswMTAwLCBKaW0gVmFubnMgd3JvdGU6DQo+IEhl
bGxvIE5GUyBoYWNrZXJzLiBGaXJzdCBvZmYsIGZlYXIgbm90IC0gdGhlIGF0dGFjaGVkIHBhdGNo
IGlzIG5vdA0KPiBzb21ldGhpbmcgSSB3aXNoIHRvIHN1Ym1pdCB0byB0aGUgbWFpbmxpbmUga2Vy
bmVsISBIb3dldmVyLCBpdCBpcw0KPiBpbXBvcnRhbnQgZm9yIG1lIHRoYXQgeW91IHBhc3MganVk
Z2VtZW50IG9yIGNvbW1lbnQgb24gaXQuIEl0IGlzIHNtYWxsLg0KPiANCj4gQmFzaWNhbGx5LCBJ
J3ZlIHdyaXR0ZW4gdGhlIHBhdGNoIHNvbGVseSB0byB3b3JrYXJvdW5kIGEgQmx1ZWFyYyBidWcN
Cj4gd2hlcmUgaXQgZHVwbGljYXRlcyBmaWxlaWRzIHdpdGhpbiBhbiBmc2lkIGFuZCB0aGVyZWZv
cmUgd2UncmUgbm90IGFibGUNCj4gdG8gcmVseSBvbiB0aGUgZnNpZCtmaWxlaWQgdG8gaWRlbnRp
ZnkgZGlzdGluY3QgZmlsZXMgaW4gYW4gTkZTDQo+IGZpbGVzeXN0ZW0uIFNvbWUgb2Ygb3VyIHN0
b3JhZ2UgaW5kZXhpbmcgYW5kIHJlcG9ydGluZyBzb2Z0d2FyZSByZWxpZXMNCj4gb24gdGhpcyBh
bmQgd29ya3MgaGFwcGlseSB3aXRoIG90aGVyLCBtb3JlIFJGQy1hZGhlcmVudA0KPiBpbXBsZW1l
bnRhdGlvbnMgOykNCj4gDQo+IFRoZSBmdW5jdGlvbmFsIGNoYW5nZSBpcyBvbmUgdGhhdCBtb2Rp
ZmllZCB0aGUgcmVjZWl2ZWQgZmlsZWlkIHRvIGEgaGFzaA0KPiBvZiB0aGUgZmlsZSBoYW5kbGUg
YXMgdGhhdCwgdGhhbmtmdWxseSwgaXMgc3RpbGwgdW5pcXVlLiBBcyB3aXRoIGENCj4gZmlsZWlk
IEkgbmVlZCB0aGlzIGhhc2ggdG8gcmVtYWluIGNvbnNpc3RlbnQgZm9yIHRoZSBsaWZldGltZSBv
ZiBhIGZpbGUuDQo+IEl0IGlzIHVzZWQgYXMgYSB1bmlxdWUgaWRlbnRpZmllciBpbiBhIGRhdGFi
YXNlLg0KPiANCj4gSSdkIHJlYWxseSBhcHByZWNpYXRlIGl0IGlmIHlvdSBjb3VsZCBsZXQgbWUg
a25vdyBvZiBhbnkgcHJvYmxlbXMgeW91DQo+IHNlZSB3aXRoIGl0IC0gd2hldGhlciBpdCdsbCBi
cmVhayBzb21lIGNsaWVudC1zaWRlIGNvZGUsIGhhc2ggdGFibGUgdXNlDQo+IG9yIHdvcnNlIHN0
aWxsIHNlbmQgYmFjayBiYWQgZGF0YSB0byB0aGUgc2VydmVyLg0KPiANCj4gSSd2ZSBtb2RpZmll
ZCB3aGF0IEkgY2FuIHNlZSBhcyB0aGUgbGVhc3QgYW1vdW50IG9mIGNvZGUgcG9zc2libGUgLSBh
bmQNCj4gbXkgdGVzdCBWTSBpcyB3b3JraW5nIGhhcHBpbHkgYXMgYSBjbGllbnQgd2l0aCB0aGlz
IHBhdGNoLiBJdCBpcw0KPiBpbnRlbmRlZCB0aGF0IHRoZSBwYXRjaCBtb2RpZmllcyBvbmx5IGNs
aWVudC1zaWRlIGNvZGUgb25jZSB0aGUgQmx1ZWFyYw0KPiBSUENzIGFyZSBwdWxsZWQgb2ZmIHRo
ZSB3aXJlLiBJIG5ldmVyIHdhbnQgdG8gc2VuZCBiYWNrIHRoZXNlIG1vZGlmaWVkDQo+IGZpbGVp
ZHMgdG8gdGhlIHNlcnZlci4NCg0KUkVBRERJUiBhbmQgUkVBRERJUlBMVVMgd2lsbCBjb250aW51
ZSB0byByZXR1cm4gdGhlIGZpbGVpZCBmcm9tIHRoZQ0Kc2VydmVyLCBzbyB0aGUgZ2V0ZGVudHMo
KSBhbmQgcmVhZGRpcigpIHN5c2NhbGxzIHdpbGwgYmUgYnJva2VuLiBTaW5jZQ0KUkVBRERJUlBM
VVMgZG9lcyByZXR1cm4gdGhlIGZpbGVoYW5kbGUsIHlvdSBtaWdodCBiZSBhYmxlIHRvIGZpeCB0
aGF0DQp1cCwgYnV0IHBsYWluIFJFQURESVIgd291bGQgYXBwZWFyIHRvIGJlIHVuZml4YWJsZS4N
Cg0KT3RoZXJ3aXNlLCB5b3VyIHN0cmF0ZWd5IHNob3VsZCBpbiBwcmluY2lwbGUgYmUgT0ssIGJ1
dCB3aXRoIHRoZSBjYXZlYXQNCnRoYXQgYSBoYXNoIGRvZXMgbm90IHN1ZmZpY2UgdG8gY29tcGxl
dGVseSBwcmV2ZW50IGNvbGxpc2lvbnMgZXZlbiBpZiBpdA0KaXMgd2VsbCBjaG9zZW4uDQpJT1c6
IEFsbCB5b3UgYXJlIGRvaW5nIGlzIHR3ZWFraW5nIHRoZSBwcm9iYWJpbGl0eSBvZiBhIGNvbGxp
c2lvbi4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5l
cg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K
DQo=

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Your comments, guidance, advice please :)
  2012-08-13 16:40 ` Myklebust, Trond
@ 2012-08-13 16:51   ` Jim Vanns
  2012-08-13 17:28   ` J. Bruce Fields
  2012-08-14 16:32   ` Jim Vanns
  2 siblings, 0 replies; 5+ messages in thread
From: Jim Vanns @ 2012-08-13 16:51 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jim Vanns, linux-nfs

On Mon, 2012-08-13 at 16:40 +0000, Myklebust, Trond wrote:
> On Mon, 2012-08-13 at 15:55 +0100, Jim Vanns wrote:
> > Hello NFS hackers. First off, fear not - the attached patch is not
> > something I wish to submit to the mainline kernel! However, it is
> > important for me that you pass judgement or comment on it. It is small.
> > 
> > Basically, I've written the patch solely to workaround a Bluearc bug
> > where it duplicates fileids within an fsid and therefore we're not able
> > to rely on the fsid+fileid to identify distinct files in an NFS
> > filesystem. Some of our storage indexing and reporting software relies
> > on this and works happily with other, more RFC-adherent
> > implementations ;)
> > 
> > The functional change is one that modified the received fileid to a hash
> > of the file handle as that, thankfully, is still unique. As with a
> > fileid I need this hash to remain consistent for the lifetime of a file.
> > It is used as a unique identifier in a database.
> > 
> > I'd really appreciate it if you could let me know of any problems you
> > see with it - whether it'll break some client-side code, hash table use
> > or worse still send back bad data to the server.
> > 
> > I've modified what I can see as the least amount of code possible - and
> > my test VM is working happily as a client with this patch. It is
> > intended that the patch modifies only client-side code once the Bluearc
> > RPCs are pulled off the wire. I never want to send back these modified
> > fileids to the server.
> 
> READDIR and READDIRPLUS will continue to return the fileid from the
> server, so the getdents() and readdir() syscalls will be broken. Since
> READDIRPLUS does return the filehandle, you might be able to fix that
> up, but plain READDIR would appear to be unfixable.

Thanks, I'll take a look at that.

> Otherwise, your strategy should in principle be OK, but with the caveat
> that a hash does not suffice to completely prevent collisions even if it
> is well chosen.
> IOW: All you are doing is tweaking the probability of a collision.

Oh yes, I completely understand that. I've done very little testing but
I'm confident that this at least reduces the number of collisions
considerably.

Jim

> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 
> NrybXǧv^)޺{.n+{"^nrz\x1ah&\x1eGh\x03(階ݢj"\x1a^[mzޖfh~m

-- 
Jim Vanns
Systems Programmer
Framestore


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Your comments, guidance, advice please :)
  2012-08-13 16:40 ` Myklebust, Trond
  2012-08-13 16:51   ` Jim Vanns
@ 2012-08-13 17:28   ` J. Bruce Fields
  2012-08-14 16:32   ` Jim Vanns
  2 siblings, 0 replies; 5+ messages in thread
From: J. Bruce Fields @ 2012-08-13 17:28 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jim Vanns, linux-nfs

On Mon, Aug 13, 2012 at 04:40:39PM +0000, Myklebust, Trond wrote:
> On Mon, 2012-08-13 at 15:55 +0100, Jim Vanns wrote:
> > Hello NFS hackers. First off, fear not - the attached patch is not
> > something I wish to submit to the mainline kernel! However, it is
> > important for me that you pass judgement or comment on it. It is small.
> > 
> > Basically, I've written the patch solely to workaround a Bluearc bug
> > where it duplicates fileids within an fsid and therefore we're not able
> > to rely on the fsid+fileid to identify distinct files in an NFS
> > filesystem. Some of our storage indexing and reporting software relies
> > on this and works happily with other, more RFC-adherent
> > implementations ;)
> > 
> > The functional change is one that modified the received fileid to a hash
> > of the file handle as that, thankfully, is still unique. As with a
> > fileid I need this hash to remain consistent for the lifetime of a file.
> > It is used as a unique identifier in a database.
> > 
> > I'd really appreciate it if you could let me know of any problems you
> > see with it - whether it'll break some client-side code, hash table use
> > or worse still send back bad data to the server.
> > 
> > I've modified what I can see as the least amount of code possible - and
> > my test VM is working happily as a client with this patch. It is
> > intended that the patch modifies only client-side code once the Bluearc
> > RPCs are pulled off the wire. I never want to send back these modified
> > fileids to the server.
> 
> READDIR and READDIRPLUS will continue to return the fileid from the
> server, so the getdents() and readdir() syscalls will be broken. Since
> READDIRPLUS does return the filehandle, you might be able to fix that
> up, but plain READDIR would appear to be unfixable.
> 
> Otherwise, your strategy should in principle be OK, but with the caveat
> that a hash does not suffice to completely prevent collisions even if it
> is well chosen.
> IOW: All you are doing is tweaking the probability of a collision.

Also: the v4 rfc's allow two distinct filehandles to point to the same
file, don't they?  (See e.g.
http://tools.ietf.org/html/rfc5661#section-10.3.4).

--b.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Your comments, guidance, advice please :)
  2012-08-13 16:40 ` Myklebust, Trond
  2012-08-13 16:51   ` Jim Vanns
  2012-08-13 17:28   ` J. Bruce Fields
@ 2012-08-14 16:32   ` Jim Vanns
  2 siblings, 0 replies; 5+ messages in thread
From: Jim Vanns @ 2012-08-14 16:32 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jim Vanns, linux-nfs

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On Mon, 2012-08-13 at 16:40 +0000, Myklebust, Trond wrote:
> On Mon, 2012-08-13 at 15:55 +0100, Jim Vanns wrote:
> > Hello NFS hackers. First off, fear not - the attached patch is not
> > something I wish to submit to the mainline kernel! However, it is
> > important for me that you pass judgement or comment on it. It is small.
> > 
> > Basically, I've written the patch solely to workaround a Bluearc bug
> > where it duplicates fileids within an fsid and therefore we're not able
> > to rely on the fsid+fileid to identify distinct files in an NFS
> > filesystem. Some of our storage indexing and reporting software relies
> > on this and works happily with other, more RFC-adherent
> > implementations ;)
> > 
> > The functional change is one that modified the received fileid to a hash
> > of the file handle as that, thankfully, is still unique. As with a
> > fileid I need this hash to remain consistent for the lifetime of a file.
> > It is used as a unique identifier in a database.
> > 
> > I'd really appreciate it if you could let me know of any problems you
> > see with it - whether it'll break some client-side code, hash table use
> > or worse still send back bad data to the server.
> > 
> > I've modified what I can see as the least amount of code possible - and
> > my test VM is working happily as a client with this patch. It is
> > intended that the patch modifies only client-side code once the Bluearc
> > RPCs are pulled off the wire. I never want to send back these modified
> > fileids to the server.
> 
> READDIR and READDIRPLUS will continue to return the fileid from the
> server, so the getdents() and readdir() syscalls will be broken. Since
> READDIRPLUS does return the filehandle, you might be able to fix that
> up, but plain READDIR would appear to be unfixable.

To this end then, I've modified my patch so that within
nfs_refresh_inode() itself I do the following:

fattr->fileid = nfs_fh_hash(NFS_FH(inode));

Before the spin lock is taken. Full patch attached again for context.

Thanks again,

Jim

> Otherwise, your strategy should in principle be OK, but with the caveat
> that a hash does not suffice to completely prevent collisions even if it
> is well chosen.
> IOW: All you are doing is tweaking the probability of a collision.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 
> NrybXǧv^)޺{.n+{"^nrz\x1ah&\x1eGh\x03(階ݢj"\x1a^[mzޖfh~m

-- 
Jim Vanns
Systems Programmer
Framestore

[-- Attachment #2: fscfc-nfs-fileid-hash-2.patch --]
[-- Type: text/x-patch, Size: 3452 bytes --]

--- linux-2.6.32/fs/nfs/inode.c.orig	2012-08-13 11:24:41.902452726 +0100
+++ linux-2.6.32/fs/nfs/inode.c	2012-08-14 14:04:37.905712353 +0100
@@ -60,6 +60,52 @@ static int nfs_update_inode(struct inode
 
 static struct kmem_cache * nfs_inode_cachep;
 
+/*
+ * FSCFC:
+ *
+ * Implementations of FNV-1 hash function:
+ * http://isthe.com/chongo/tech/comp/fnv
+ * http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash#Notes
+ */
+static inline uint32_t
+nfs_fh_hash32(struct nfs_fh *fh)
+{
+    static const uint32_t seed = 2166136261U,
+                          prime = 16777619U;
+    uint32_t hash = seed, i = 0;
+
+    while (i < fh->size) {
+        hash = (hash * prime) ^ fh->data[i];
+        ++i;
+    }
+
+    return hash;
+}
+
+static inline uint64_t
+nfs_fh_hash64(struct nfs_fh *fh)
+{
+    static const uint64_t seed = 14695981039346656037U,
+                          prime = 1099511628211U;
+    uint64_t hash = seed, i = 0;
+
+    while (i < fh->size) {
+        hash = (hash * prime) ^ fh->data[i];
+        ++i;
+    }
+
+    return hash;
+}
+
+static inline unsigned long
+nfs_fh_hash(struct nfs_fh *fh)
+{
+    if (sizeof(unsigned long) == 4)
+        return nfs_fh_hash32(fh);
+
+    return nfs_fh_hash64(fh);
+}
+
 static inline unsigned long
 nfs_fattr_to_ino_t(struct nfs_fattr *fattr)
 {
@@ -268,7 +314,28 @@ nfs_fhget(struct super_block *sb, struct
 	if ((fattr->valid & NFS_ATTR_FATTR_TYPE) == 0)
 		goto out_no_inode;
 
-	hash = nfs_fattr_to_ino_t(fattr);
+    /* 
+     * FSCFC:
+     *
+     * This patch exists solely to work around the Bluearc duplicate inode/NFS
+     * fileid bug. On Bluearc filesystems a distinct, non-hardlinked file or
+     * directory appears to share the same fsid + fileid with other completely
+     * unrelated files elsewhere in the hierarchy. This becomes a problem for
+     * any system dependent on the commonly accpepted notion of the NFSv3 fsid
+     * and fileid uniquely identifying a single file/directory within an NFS
+     * filesystem. Thankfully, the NFS file handle for any duplications are
+     * still unique :)
+     *
+     * We must update *both* the hash value (was the i_ino/fileid as returned
+     * by nfs_fattr_to_ino_t() above) and fileid here as it is used as the key
+     * in the inode cache maintained within iget5_locked() below.
+     *
+     * We set fattr->fileid to 'hash' to because NFS_FILEID and set_nfs_fileid()
+     * just copy/return 'fileid' from this structure which the server has
+     * already sent as the inode on it's filesystem as you'd expect. This is
+     * what we overwrite - client side only.
+     */
+    fattr->fileid = hash = nfs_fh_hash(fh); // JV alternate code
 
 	inode = iget5_locked(sb, hash, nfs_find_actor, nfs_init_locked, &desc);
 	if (inode == NULL) {
@@ -907,7 +974,6 @@ static int nfs_check_inode_attributes(st
 	loff_t cur_size, new_isize;
 	unsigned long invalid = 0;
 
-
 	/* Has the inode gone and changed behind our back? */
 	if ((fattr->valid & NFS_ATTR_FATTR_FILEID) && nfsi->fileid != fattr->fileid)
 		return -EIO;
@@ -1036,6 +1102,12 @@ int nfs_refresh_inode(struct inode *inod
 
 	if ((fattr->valid & NFS_ATTR_FATTR) == 0)
 		return 0;
+
+    /*
+     * FSCFC: Compare against the hashed file handle, not the fileid
+     */
+    fattr->fileid = nfs_fh_hash(NFS_FH(inode)); // JV alternate code
+
 	spin_lock(&inode->i_lock);
 	status = nfs_refresh_inode_locked(inode, fattr);
 	spin_unlock(&inode->i_lock);

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-08-14 16:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-13 14:55 Your comments, guidance, advice please :) Jim Vanns
2012-08-13 16:40 ` Myklebust, Trond
2012-08-13 16:51   ` Jim Vanns
2012-08-13 17:28   ` J. Bruce Fields
2012-08-14 16:32   ` Jim Vanns

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.