Re: Another try at LNFS?

Dave Quigley <dpquigl@xxxxxxxxxxxxxxx> · Tue, 08 May 2012 01:24:50 -0400

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


Re: Another try at LNFS?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]