Re: Another try at LNFS?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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! TrondI 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 majordomoinfoat http://vger.kernel.org/majordomo-info.htmlLooking 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