On 4/5/2012 10:20 PM, Myklebust, Trond wrote:
-----Original Message-----
From: David Quigley [mailto:dpquigl@xxxxxxxxxxxxxxx]
Sent: Thursday, April 05, 2012 2:38 PM
To: Myklebust, Trond
Cc: linux-nfs@xxxxxxxxxxxxxxx
Subject: Re: Another try at LNFS?
On 04/05/2012 17:26, David Quigley wrote:
On 04/05/2012 13:15, Myklebust, Trond wrote:
On Thu, 2012-04-05 at 13:02 -0400, David Quigley wrote:
Now that we're past the 3.4 merge window should I post the LNFS
modifications for review for when 3.5 rolls around?
The sooner the better. It looks as if there will be quite a bit of
stuff going into 3.5, so it would be nice to maximise our testing
window.
Thanks!
Trond
I have a mostly working copy for 3.2 which I can forward port but I'm
having an issue with it. The revalidate code changed at some point and
just to get things working I dropped a piece of code from the patch
set that I couldn't figure out how to transition to the new revalidate
code. Unfortunately this is the initial get of the security label so
the security label is invalid until the first cache invalidation. Any
suggestions on where to place this code? I can give you the original
code snippet when I get home that I dropped.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs"
in
the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
info
at http://vger.kernel.org/majordomo-info.html
Looking at my patches it looks like nfs_lookup_revalidate was changed and at
the time I couldn't figure out what it was changed to.
Hi Dave,
There shouldn't be much in the way of changes in nfs_lookup_revalidate(): I was just trying to clean it up in preparation for the atomic open patches that Miklos is currently working on.
At this point, it looks as if most of that functionality will in any case be moved into the struct file_operations->open callback, so that we can keep ->d_revalidate() as a pure lookup function.
Cheers
Trond
Ok I looked at the code again finally and I think I figured out the
problem. nfs_prime_dcache is new and there are a couple of calls in
there that should be taking a label that I just passed null to. We don't
store the nfs4_label in the inode so I'm not sure how to get the label
back for the nfs_refresh_inode call and then we have a call to nfs_fhget
which would normally get us label data. I think the nature of this
function is what I don't quite understand. When is it called? What I
think is happening is that I should be pulling the label data into the
inode in this function but I'm not because I'm passing nulls here. if I
figure out how to get real label data into the inode at this point I
should be able to fix the bug where we aren't getting labels until the
first cache invalidation.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
