* Another try at LNFS? @ 2012-04-05 17:02 David Quigley 2012-04-05 17:15 ` Myklebust, Trond 0 siblings, 1 reply; 9+ messages in thread From: David Quigley @ 2012-04-05 17:02 UTC (permalink / raw) To: linux-nfs Now that we're past the 3.4 merge window should I post the LNFS modifications for review for when 3.5 rolls around? Dave ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-04-05 17:02 Another try at LNFS? David Quigley @ 2012-04-05 17:15 ` Myklebust, Trond 2012-04-05 21:26 ` David Quigley 0 siblings, 1 reply; 9+ messages in thread From: Myklebust, Trond @ 2012-04-05 17:15 UTC (permalink / raw) To: David Quigley; +Cc: linux-nfs@vger.kernel.org T24gVGh1LCAyMDEyLTA0LTA1IGF0IDEzOjAyIC0wNDAwLCBEYXZpZCBRdWlnbGV5IHdyb3RlOg0K PiBOb3cgdGhhdCB3ZSdyZSBwYXN0IHRoZSAzLjQgbWVyZ2Ugd2luZG93IHNob3VsZCBJIHBvc3Qg dGhlIExORlMgDQo+IG1vZGlmaWNhdGlvbnMgZm9yIHJldmlldyBmb3Igd2hlbiAzLjUgcm9sbHMg YXJvdW5kPw0KDQpUaGUgc29vbmVyIHRoZSBiZXR0ZXIuIEl0IGxvb2tzIGFzIGlmIHRoZXJlIHdp bGwgYmUgcXVpdGUgYSBiaXQgb2Ygc3R1ZmYNCmdvaW5nIGludG8gMy41LCBzbyBpdCB3b3VsZCBi ZSBuaWNlIHRvIG1heGltaXNlIG91ciB0ZXN0aW5nIHdpbmRvdy4NCg0KVGhhbmtzIQ0KICBUcm9u ZA0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoN Ck5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-04-05 17:15 ` Myklebust, Trond @ 2012-04-05 21:26 ` David Quigley 2012-04-05 21:38 ` David Quigley 0 siblings, 1 reply; 9+ messages in thread From: David Quigley @ 2012-04-05 21:26 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-04-05 21:26 ` David Quigley @ 2012-04-05 21:38 ` David Quigley 2012-04-06 2:20 ` Myklebust, Trond 0 siblings, 1 reply; 9+ messages in thread From: David Quigley @ 2012-04-05 21:38 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs 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@vger.kernel.org > 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. Dave ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Another try at LNFS? 2012-04-05 21:38 ` David Quigley @ 2012-04-06 2:20 ` Myklebust, Trond 2012-04-06 13:13 ` David Quigley 2012-05-08 5:24 ` Dave Quigley 0 siblings, 2 replies; 9+ messages in thread From: Myklebust, Trond @ 2012-04-06 2:20 UTC (permalink / raw) To: David Quigley; +Cc: linux-nfs@vger.kernel.org PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZpZCBRdWlnbGV5IFttYWls dG86ZHBxdWlnbEBkYXZlcXVpZ2xleS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNSwg MjAxMiAyOjM4IFBNDQo+IFRvOiBNeWtsZWJ1c3QsIFRyb25kDQo+IENjOiBsaW51eC1uZnNAdmdl ci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBBbm90aGVyIHRyeSBhdCBMTkZTPw0KPiANCj4g T24gMDQvMDUvMjAxMiAxNzoyNiwgRGF2aWQgUXVpZ2xleSB3cm90ZToNCj4gPiBPbiAwNC8wNS8y MDEyIDEzOjE1LCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+PiBPbiBUaHUsIDIwMTItMDQt MDUgYXQgMTM6MDIgLTA0MDAsIERhdmlkIFF1aWdsZXkgd3JvdGU6DQo+ID4+PiBOb3cgdGhhdCB3 ZSdyZSBwYXN0IHRoZSAzLjQgbWVyZ2Ugd2luZG93IHNob3VsZCBJIHBvc3QgdGhlIExORlMNCj4g Pj4+IG1vZGlmaWNhdGlvbnMgZm9yIHJldmlldyBmb3Igd2hlbiAzLjUgcm9sbHMgYXJvdW5kPw0K PiA+Pg0KPiA+PiBUaGUgc29vbmVyIHRoZSBiZXR0ZXIuIEl0IGxvb2tzIGFzIGlmIHRoZXJlIHdp bGwgYmUgcXVpdGUgYSBiaXQgb2YNCj4gPj4gc3R1ZmYgZ29pbmcgaW50byAzLjUsIHNvIGl0IHdv dWxkIGJlIG5pY2UgdG8gbWF4aW1pc2Ugb3VyIHRlc3RpbmcNCj4gPj4gd2luZG93Lg0KPiA+Pg0K PiA+PiBUaGFua3MhDQo+ID4+ICAgVHJvbmQNCj4gPg0KPiA+IEkgaGF2ZSBhIG1vc3RseSB3b3Jr aW5nIGNvcHkgZm9yIDMuMiB3aGljaCBJIGNhbiBmb3J3YXJkIHBvcnQgYnV0IEknbQ0KPiA+IGhh dmluZyBhbiBpc3N1ZSB3aXRoIGl0LiBUaGUgcmV2YWxpZGF0ZSBjb2RlIGNoYW5nZWQgYXQgc29t ZSBwb2ludCBhbmQNCj4gPiBqdXN0IHRvIGdldCB0aGluZ3Mgd29ya2luZyBJIGRyb3BwZWQgYSBw aWVjZSBvZiBjb2RlIGZyb20gdGhlIHBhdGNoDQo+ID4gc2V0IHRoYXQgSSBjb3VsZG4ndCBmaWd1 cmUgb3V0IGhvdyB0byB0cmFuc2l0aW9uIHRvIHRoZSBuZXcgcmV2YWxpZGF0ZQ0KPiA+IGNvZGUu IFVuZm9ydHVuYXRlbHkgdGhpcyBpcyB0aGUgaW5pdGlhbCBnZXQgb2YgdGhlIHNlY3VyaXR5IGxh YmVsIHNvDQo+ID4gdGhlIHNlY3VyaXR5IGxhYmVsIGlzIGludmFsaWQgdW50aWwgdGhlIGZpcnN0 IGNhY2hlIGludmFsaWRhdGlvbi4gQW55DQo+ID4gc3VnZ2VzdGlvbnMgb24gd2hlcmUgdG8gcGxh Y2UgdGhpcyBjb2RlPyBJIGNhbiBnaXZlIHlvdSB0aGUgb3JpZ2luYWwNCj4gPiBjb2RlIHNuaXBw ZXQgd2hlbiBJIGdldCBob21lIHRoYXQgSSBkcm9wcGVkLg0KPiA+DQo+ID4gRGF2ZQ0KPiA+IC0t DQo+ID4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vi c2NyaWJlIGxpbnV4LW5mcyINCj4gPiBpbg0KPiA+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBt YWpvcmRvbW9Admdlci5rZXJuZWwub3JnIE1vcmUgbWFqb3Jkb21vDQo+IGluZm8NCj4gPiBhdCAg aHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+IA0KPiBMb29raW5n IGF0IG15IHBhdGNoZXMgaXQgbG9va3MgbGlrZSBuZnNfbG9va3VwX3JldmFsaWRhdGUgd2FzIGNo YW5nZWQgYW5kIGF0DQo+IHRoZSB0aW1lIEkgY291bGRuJ3QgZmlndXJlIG91dCB3aGF0IGl0IHdh cyBjaGFuZ2VkIHRvLg0KDQpIaSBEYXZlLA0KICBUaGVyZSBzaG91bGRuJ3QgYmUgbXVjaCBpbiB0 aGUgd2F5IG9mIGNoYW5nZXMgaW4gbmZzX2xvb2t1cF9yZXZhbGlkYXRlKCk6IEkgd2FzIGp1c3Qg dHJ5aW5nIHRvIGNsZWFuIGl0IHVwIGluIHByZXBhcmF0aW9uIGZvciB0aGUgYXRvbWljIG9wZW4g cGF0Y2hlcyB0aGF0IE1pa2xvcyBpcyBjdXJyZW50bHkgd29ya2luZyBvbi4NCkF0IHRoaXMgcG9p bnQsIGl0IGxvb2tzIGFzIGlmIG1vc3Qgb2YgdGhhdCBmdW5jdGlvbmFsaXR5IHdpbGwgaW4gYW55 IGNhc2UgYmUgbW92ZWQgaW50byB0aGUgc3RydWN0IGZpbGVfb3BlcmF0aW9ucy0+b3BlbiBjYWxs YmFjaywgc28gdGhhdCB3ZSBjYW4ga2VlcCAtPmRfcmV2YWxpZGF0ZSgpIGFzIGEgcHVyZSBsb29r dXAgZnVuY3Rpb24uDQoNCkNoZWVycw0KICBUcm9uZA0K ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Another try at LNFS? 2012-04-06 2:20 ` Myklebust, Trond @ 2012-04-06 13:13 ` David Quigley 2012-05-08 5:24 ` Dave Quigley 1 sibling, 0 replies; 9+ messages in thread From: David Quigley @ 2012-04-06 13:13 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs On 04/05/2012 22:20, Myklebust, Trond wrote: >> -----Original Message----- >> From: David Quigley [mailto:dpquigl@davequigley.com] >> Sent: Thursday, April 05, 2012 2:38 PM >> To: Myklebust, Trond >> Cc: linux-nfs@vger.kernel.org >> 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@vger.kernel.org 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'll try to take a look at it next week since I head out of town for the weekend starting this afternoon. If I run into any other problems I'll check back with you guys. After that forward porting shouldn't be much of an issue its just time consuming and unfortunately my time is limited as of late. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-04-06 2:20 ` Myklebust, Trond 2012-04-06 13:13 ` David Quigley @ 2012-05-08 5:24 ` Dave Quigley 2012-05-08 14:46 ` Myklebust, Trond 1 sibling, 1 reply; 9+ messages in thread From: Dave Quigley @ 2012-05-08 5:24 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs@vger.kernel.org On 4/5/2012 10:20 PM, Myklebust, Trond wrote: >> -----Original Message----- >> From: David Quigley [mailto:dpquigl@davequigley.com] >> Sent: Thursday, April 05, 2012 2:38 PM >> To: Myklebust, Trond >> Cc: linux-nfs@vger.kernel.org >> 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@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-05-08 5:24 ` Dave Quigley @ 2012-05-08 14:46 ` Myklebust, Trond 2012-05-08 16:25 ` David Quigley 0 siblings, 1 reply; 9+ messages in thread From: Myklebust, Trond @ 2012-05-08 14:46 UTC (permalink / raw) To: Dave Quigley; +Cc: linux-nfs@vger.kernel.org T24gVHVlLCAyMDEyLTA1LTA4IGF0IDAxOjI0IC0wNDAwLCBEYXZlIFF1aWdsZXkgd3JvdGU6DQo+ IE9uIDQvNS8yMDEyIDEwOjIwIFBNLCBNeWtsZWJ1c3QsIFRyb25kIHdyb3RlOg0KPiA+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBEYXZpZCBRdWlnbGV5IFttYWlsdG86 ZHBxdWlnbEBkYXZlcXVpZ2xleS5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNSwg MjAxMiAyOjM4IFBNDQo+ID4+IFRvOiBNeWtsZWJ1c3QsIFRyb25kDQo+ID4+IENjOiBsaW51eC1u ZnNAdmdlci5rZXJuZWwub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBBbm90aGVyIHRyeSBhdCBMTkZT Pw0KPiA+Pg0KPiA+PiBPbiAwNC8wNS8yMDEyIDE3OjI2LCBEYXZpZCBRdWlnbGV5IHdyb3RlOg0K PiA+Pj4gT24gMDQvMDUvMjAxMiAxMzoxNSwgTXlrbGVidXN0LCBUcm9uZCB3cm90ZToNCj4gPj4+ PiBPbiBUaHUsIDIwMTItMDQtMDUgYXQgMTM6MDIgLTA0MDAsIERhdmlkIFF1aWdsZXkgd3JvdGU6 DQo+ID4+Pj4+IE5vdyB0aGF0IHdlJ3JlIHBhc3QgdGhlIDMuNCBtZXJnZSB3aW5kb3cgc2hvdWxk IEkgcG9zdCB0aGUgTE5GUw0KPiA+Pj4+PiBtb2RpZmljYXRpb25zIGZvciByZXZpZXcgZm9yIHdo ZW4gMy41IHJvbGxzIGFyb3VuZD8NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBzb29uZXIgdGhlIGJldHRl ci4gSXQgbG9va3MgYXMgaWYgdGhlcmUgd2lsbCBiZSBxdWl0ZSBhIGJpdCBvZg0KPiA+Pj4+IHN0 dWZmIGdvaW5nIGludG8gMy41LCBzbyBpdCB3b3VsZCBiZSBuaWNlIHRvIG1heGltaXNlIG91ciB0 ZXN0aW5nDQo+ID4+Pj4gd2luZG93Lg0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIQ0KPiA+Pj4+ICAg IFRyb25kDQo+ID4+Pg0KPiA+Pj4gSSBoYXZlIGEgbW9zdGx5IHdvcmtpbmcgY29weSBmb3IgMy4y IHdoaWNoIEkgY2FuIGZvcndhcmQgcG9ydCBidXQgSSdtDQo+ID4+PiBoYXZpbmcgYW4gaXNzdWUg d2l0aCBpdC4gVGhlIHJldmFsaWRhdGUgY29kZSBjaGFuZ2VkIGF0IHNvbWUgcG9pbnQgYW5kDQo+ ID4+PiBqdXN0IHRvIGdldCB0aGluZ3Mgd29ya2luZyBJIGRyb3BwZWQgYSBwaWVjZSBvZiBjb2Rl IGZyb20gdGhlIHBhdGNoDQo+ID4+PiBzZXQgdGhhdCBJIGNvdWxkbid0IGZpZ3VyZSBvdXQgaG93 IHRvIHRyYW5zaXRpb24gdG8gdGhlIG5ldyByZXZhbGlkYXRlDQo+ID4+PiBjb2RlLiBVbmZvcnR1 bmF0ZWx5IHRoaXMgaXMgdGhlIGluaXRpYWwgZ2V0IG9mIHRoZSBzZWN1cml0eSBsYWJlbCBzbw0K PiA+Pj4gdGhlIHNlY3VyaXR5IGxhYmVsIGlzIGludmFsaWQgdW50aWwgdGhlIGZpcnN0IGNhY2hl IGludmFsaWRhdGlvbi4gQW55DQo+ID4+PiBzdWdnZXN0aW9ucyBvbiB3aGVyZSB0byBwbGFjZSB0 aGlzIGNvZGU/IEkgY2FuIGdpdmUgeW91IHRoZSBvcmlnaW5hbA0KPiA+Pj4gY29kZSBzbmlwcGV0 IHdoZW4gSSBnZXQgaG9tZSB0aGF0IEkgZHJvcHBlZC4NCj4gPj4+DQo+ID4+PiBEYXZlDQo+ID4+ PiAtLQ0KPiA+Pj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUg InVuc3Vic2NyaWJlIGxpbnV4LW5mcyINCj4gPj4+IGluDQo+ID4+PiB0aGUgYm9keSBvZiBhIG1l c3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZyBNb3JlIG1ham9yZG9tbw0KPiA+PiBp bmZvDQo+ID4+PiBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1s DQo+ID4+DQo+ID4+IExvb2tpbmcgYXQgbXkgcGF0Y2hlcyBpdCBsb29rcyBsaWtlIG5mc19sb29r dXBfcmV2YWxpZGF0ZSB3YXMgY2hhbmdlZCBhbmQgYXQNCj4gPj4gdGhlIHRpbWUgSSBjb3VsZG4n dCBmaWd1cmUgb3V0IHdoYXQgaXQgd2FzIGNoYW5nZWQgdG8uDQo+ID4NCj4gPiBIaSBEYXZlLA0K PiA+ICAgIFRoZXJlIHNob3VsZG4ndCBiZSBtdWNoIGluIHRoZSB3YXkgb2YgY2hhbmdlcyBpbiBu ZnNfbG9va3VwX3JldmFsaWRhdGUoKTogSSB3YXMganVzdCB0cnlpbmcgdG8gY2xlYW4gaXQgdXAg aW4gcHJlcGFyYXRpb24gZm9yIHRoZSBhdG9taWMgb3BlbiBwYXRjaGVzIHRoYXQgTWlrbG9zIGlz IGN1cnJlbnRseSB3b3JraW5nIG9uLg0KPiA+IEF0IHRoaXMgcG9pbnQsIGl0IGxvb2tzIGFzIGlm IG1vc3Qgb2YgdGhhdCBmdW5jdGlvbmFsaXR5IHdpbGwgaW4gYW55IGNhc2UgYmUgbW92ZWQgaW50 byB0aGUgc3RydWN0IGZpbGVfb3BlcmF0aW9ucy0+b3BlbiBjYWxsYmFjaywgc28gdGhhdCB3ZSBj YW4ga2VlcCAtPmRfcmV2YWxpZGF0ZSgpIGFzIGEgcHVyZSBsb29rdXAgZnVuY3Rpb24uDQo+ID4N Cj4gPiBDaGVlcnMNCj4gPiAgICBUcm9uZA0KPiANCj4gDQo+IE9rIEkgbG9va2VkIGF0IHRoZSBj b2RlIGFnYWluIGZpbmFsbHkgYW5kIEkgdGhpbmsgSSBmaWd1cmVkIG91dCB0aGUgDQo+IHByb2Js ZW0uIG5mc19wcmltZV9kY2FjaGUgaXMgbmV3IGFuZCB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgY2Fs bHMgaW4gDQo+IHRoZXJlIHRoYXQgc2hvdWxkIGJlIHRha2luZyBhIGxhYmVsIHRoYXQgSSBqdXN0 IHBhc3NlZCBudWxsIHRvLiBXZSBkb24ndCANCj4gc3RvcmUgdGhlIG5mczRfbGFiZWwgaW4gdGhl IGlub2RlIHNvIEknbSBub3Qgc3VyZSBob3cgdG8gZ2V0IHRoZSBsYWJlbCANCj4gYmFjayBmb3Ig dGhlIG5mc19yZWZyZXNoX2lub2RlIGNhbGwgYW5kIHRoZW4gd2UgaGF2ZSBhIGNhbGwgdG8gbmZz X2ZoZ2V0IA0KPiB3aGljaCB3b3VsZCBub3JtYWxseSBnZXQgdXMgbGFiZWwgZGF0YS4gSSB0aGlu ayB0aGUgbmF0dXJlIG9mIHRoaXMgDQo+IGZ1bmN0aW9uIGlzIHdoYXQgSSBkb24ndCBxdWl0ZSB1 bmRlcnN0YW5kLiBXaGVuIGlzIGl0IGNhbGxlZD8gV2hhdCBJIA0KPiB0aGluayBpcyBoYXBwZW5p bmcgaXMgdGhhdCBJIHNob3VsZCBiZSBwdWxsaW5nIHRoZSBsYWJlbCBkYXRhIGludG8gdGhlIA0K PiBpbm9kZSBpbiB0aGlzIGZ1bmN0aW9uIGJ1dCBJJ20gbm90IGJlY2F1c2UgSSdtIHBhc3Npbmcg bnVsbHMgaGVyZS4gaWYgSSANCj4gZmlndXJlIG91dCBob3cgdG8gZ2V0IHJlYWwgbGFiZWwgZGF0 YSBpbnRvIHRoZSBpbm9kZSBhdCB0aGlzIHBvaW50IEkgDQo+IHNob3VsZCBiZSBhYmxlIHRvIGZp eCB0aGUgYnVnIHdoZXJlIHdlIGFyZW4ndCBnZXR0aW5nIGxhYmVscyB1bnRpbCB0aGUgDQo+IGZp cnN0IGNhY2hlIGludmFsaWRhdGlvbi4NCj4gDQo+IERhdmUNCg0KbmZzX3ByaW1lX2RjYWNoZSBp cyBjYWxsZWQgYWZ0ZXIgYSBSRUFERElSUExVUyBvcGVyYXRpb24uIEluIHRoZSBjYXNlIG9mDQpO RlN2NCwgdGhhdCBtZWFucyB0aGF0IHdlIHJlcXVlc3QgYSBmaWxlaGFuZGxlIGFuZCBmdWxsIGZp bGUgYXR0cmlidXRlcw0KaW4gb3VyIFJFQURESVIgb3BlcmF0aW9uLiBXZSB0aGVuIHVzZSB0aGUg cmVzdWx0cyB0byBjcmVhdGUgZGVudHJpZXMNCnRoYXQgd2UgdGhlbiBwb3B1bGF0ZSB0aGUgZGNh Y2hlIHdpdGg6DQpJT1c6IGFzIGZhciBhcyB0aGUgVkZTIGlzIGNvbmNlcm5lZCwgaXQgbG9va3Mg YXMgaWYgd2UndmUgZG9uZSBhIGJ1bmNoDQpvZiBsb29rdXBzIG9mIHRoZXNlIGZpbGVzLg0KDQot LSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFw cA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Another try at LNFS? 2012-05-08 14:46 ` Myklebust, Trond @ 2012-05-08 16:25 ` David Quigley 0 siblings, 0 replies; 9+ messages in thread From: David Quigley @ 2012-05-08 16:25 UTC (permalink / raw) To: Myklebust, Trond; +Cc: linux-nfs On 05/08/2012 10:46, Myklebust, Trond wrote: > 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@davequigley.com] >> >> Sent: Thursday, April 05, 2012 2:38 PM >> >> To: Myklebust, Trond >> >> Cc: linux-nfs@vger.kernel.org >> >> 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@vger.kernel.org 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. Does it seem like this might be the problem area though or am I barking up the wrong tree? I could look through my porting again and make sure I didn't miss anything but that would take a lot of time I don't have at the moment. I have a telecon tonight at 9pm with some people in Asia who want to help with development so I may have them look into this bug and try to take care of it. After that it should just be a forward port to 3.5/3.6. Dave ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-05-08 16:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-05 17:02 Another try at LNFS? David Quigley 2012-04-05 17:15 ` Myklebust, Trond 2012-04-05 21:26 ` David Quigley 2012-04-05 21:38 ` David Quigley 2012-04-06 2:20 ` Myklebust, Trond 2012-04-06 13:13 ` David Quigley 2012-05-08 5:24 ` Dave Quigley 2012-05-08 14:46 ` Myklebust, Trond 2012-05-08 16:25 ` David Quigley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).