On Tue, 2012-05-08 at 01:24 -0400, Dave Quigley wrote: > 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 nfs_prime_dcache is called after a READDIRPLUS operation. In the case of NFSv4, that means that we request a filehandle and full file attributes in our READDIR operation. We then use the results to create dentries that we then populate the dcache with: IOW: as far as the VFS is concerned, it looks as if we've done a bunch of lookups of these files. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
