* global openowner_id and lockowner_id @ 2012-04-12 15:42 Chuck Lever 2012-04-12 15:50 ` Myklebust, Trond 0 siblings, 1 reply; 7+ messages in thread From: Chuck Lever @ 2012-04-12 15:42 UTC (permalink / raw) To: Trond Myklebust; +Cc: Linux NFS Mailing List Hi- Changing the SETCLIENTID boot verifier so it is global for the whole client exposes a problem with how we allocate state owners. A quick umount / mount sequence destroys all state on the client. But since the client now always uses the same boot verifier and nfs_client_id4 string, the server no longer recognizes a client reboot. FOr a fresh mount, the client may perform a SETCLIENTID, but it is treated as a callback update (state is not purged) if the client's lease has not yet expired. Our state owners are generated from a pair of ida structures in the nfs_server for that mount. They always start from zero after a mount operation. Likewise, the sequence IDs for these state owners are also reset by umount / mount. Note that each mount point gets a fresh nfs_server, so these structures are not retained across umount / mount. This means umount / mount with no lease expiry starts to re-play state owners with reset sequence IDs. Servers don't really care for that behavior. I have a test case that reliably gets a BAD_SEQID error from a server after a quick umount / mount followed by a single file creation. Now that we are about to switch to using more-or-less global SETCLIENTID boot verifiers, it seems to me that we really want a global openowner_id and lockowner_id as well. The performance impact of such a change might be acceptable because we cache and reuse state owners now. Thoughts? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 15:42 global openowner_id and lockowner_id Chuck Lever @ 2012-04-12 15:50 ` Myklebust, Trond 2012-04-12 15:54 ` Chuck Lever 0 siblings, 1 reply; 7+ messages in thread From: Myklebust, Trond @ 2012-04-12 15:50 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List T24gVGh1LCAyMDEyLTA0LTEyIGF0IDExOjQyIC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g SGktDQo+IA0KPiBDaGFuZ2luZyB0aGUgU0VUQ0xJRU5USUQgYm9vdCB2ZXJpZmllciBzbyBpdCBp cyBnbG9iYWwgZm9yIHRoZSB3aG9sZSBjbGllbnQgZXhwb3NlcyBhIHByb2JsZW0gd2l0aCBob3cg d2UgYWxsb2NhdGUgc3RhdGUgb3duZXJzLg0KPiANCj4gQSBxdWljayB1bW91bnQgLyBtb3VudCBz ZXF1ZW5jZSBkZXN0cm95cyBhbGwgc3RhdGUgb24gdGhlIGNsaWVudC4gIEJ1dCBzaW5jZSB0aGUg Y2xpZW50IG5vdyBhbHdheXMgdXNlcyB0aGUgc2FtZSBib290IHZlcmlmaWVyIGFuZCBuZnNfY2xp ZW50X2lkNCBzdHJpbmcsIHRoZSBzZXJ2ZXIgbm8gbG9uZ2VyIHJlY29nbml6ZXMgYSBjbGllbnQg cmVib290LiAgRk9yIGEgZnJlc2ggbW91bnQsIHRoZSBjbGllbnQgbWF5IHBlcmZvcm0gYSBTRVRD TElFTlRJRCwgYnV0IGl0IGlzIHRyZWF0ZWQgYXMgYSBjYWxsYmFjayB1cGRhdGUgKHN0YXRlIGlz IG5vdCBwdXJnZWQpIGlmIHRoZSBjbGllbnQncyBsZWFzZSBoYXMgbm90IHlldCBleHBpcmVkLg0K PiANCj4gT3VyIHN0YXRlIG93bmVycyBhcmUgZ2VuZXJhdGVkIGZyb20gYSBwYWlyIG9mIGlkYSBz dHJ1Y3R1cmVzIGluIHRoZSBuZnNfc2VydmVyIGZvciB0aGF0IG1vdW50LiAgVGhleSBhbHdheXMg c3RhcnQgZnJvbSB6ZXJvIGFmdGVyIGEgbW91bnQgb3BlcmF0aW9uLiAgTGlrZXdpc2UsIHRoZSBz ZXF1ZW5jZSBJRHMgZm9yIHRoZXNlIHN0YXRlIG93bmVycyBhcmUgYWxzbyByZXNldCBieSB1bW91 bnQgLyBtb3VudC4gIE5vdGUgdGhhdCBlYWNoIG1vdW50IHBvaW50IGdldHMgYSBmcmVzaCBuZnNf c2VydmVyLCBzbyB0aGVzZSBzdHJ1Y3R1cmVzIGFyZSBub3QgcmV0YWluZWQgYWNyb3NzIHVtb3Vu dCAvIG1vdW50Lg0KPiANCj4gVGhpcyBtZWFucyB1bW91bnQgLyBtb3VudCB3aXRoIG5vIGxlYXNl IGV4cGlyeSBzdGFydHMgdG8gcmUtcGxheSBzdGF0ZSBvd25lcnMgd2l0aCByZXNldCBzZXF1ZW5j ZSBJRHMuICBTZXJ2ZXJzIGRvbid0IHJlYWxseSBjYXJlIGZvciB0aGF0IGJlaGF2aW9yLiAgSSBo YXZlIGEgdGVzdCBjYXNlIHRoYXQgcmVsaWFibHkgZ2V0cyBhIEJBRF9TRVFJRCBlcnJvciBmcm9t IGEgc2VydmVyIGFmdGVyIGEgcXVpY2sgdW1vdW50IC8gbW91bnQgZm9sbG93ZWQgYnkgYSBzaW5n bGUgZmlsZSBjcmVhdGlvbi4NCj4gDQo+IE5vdyB0aGF0IHdlIGFyZSBhYm91dCB0byBzd2l0Y2gg dG8gdXNpbmcgbW9yZS1vci1sZXNzIGdsb2JhbCBTRVRDTElFTlRJRCBib290IHZlcmlmaWVycywg aXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSByZWFsbHkgd2FudCBhIGdsb2JhbCBvcGVub3duZXJfaWQg YW5kIGxvY2tvd25lcl9pZCBhcyB3ZWxsLg0KPiANCj4gVGhlIHBlcmZvcm1hbmNlIGltcGFjdCBv ZiBzdWNoIGEgY2hhbmdlIG1pZ2h0IGJlIGFjY2VwdGFibGUgYmVjYXVzZSB3ZSBjYWNoZSBhbmQg cmV1c2Ugc3RhdGUgb3duZXJzIG5vdy4NCj4gDQo+IFRob3VnaHRzPw0KDQpUaGF0J3MgYSBkZWZp bml0ZSBzZXJ2ZXIgYnVnLiBJZiB0aGUgY2xpZW50IGhvbGRzIG5vIG9wZW4gc3RhdGUsIHRoZW4g aXQNCmlzIGFsbG93ZWQgdG8gZm9yZ2V0IHRoZSBvcGVuIG93bmVyIGFuZCBzdGFydCB0aGUgc2Vx dWVuY2UgaWQgZnJvbSAwDQphZ2Fpbi4gSXQgaXMgbm90IHJlcXVpcmVkIHRvIHJlbWVtYmVyIHNl cXVlbmNlIGlkcyBmb3Igb3BlbiBvd25lcnMgdGhhdA0KYXJlbid0IGluIHVzZS4NCg0KT3VyIGN1 cnJlbnQgY2xpZW50IGNvdWxkIGVhc2lseSB0cmlnZ2VyIHRoaXMgYnVnIGV2ZW4gd2l0aG91dCBh DQp1bW91bnQvbW91bnQuDQoNCkNoZWVycw0KICBUcm9uZA0KDQotLSANClRyb25kIE15a2xlYnVz dA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0 QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 15:50 ` Myklebust, Trond @ 2012-04-12 15:54 ` Chuck Lever 2012-04-12 15:58 ` Myklebust, Trond 0 siblings, 1 reply; 7+ messages in thread From: Chuck Lever @ 2012-04-12 15:54 UTC (permalink / raw) To: Myklebust, Trond; +Cc: Linux NFS Mailing List On Apr 12, 2012, at 11:50 AM, Myklebust, Trond wrote: > On Thu, 2012-04-12 at 11:42 -0400, Chuck Lever wrote: >> Hi- >> >> Changing the SETCLIENTID boot verifier so it is global for the whole client exposes a problem with how we allocate state owners. >> >> A quick umount / mount sequence destroys all state on the client. But since the client now always uses the same boot verifier and nfs_client_id4 string, the server no longer recognizes a client reboot. FOr a fresh mount, the client may perform a SETCLIENTID, but it is treated as a callback update (state is not purged) if the client's lease has not yet expired. >> >> Our state owners are generated from a pair of ida structures in the nfs_server for that mount. They always start from zero after a mount operation. Likewise, the sequence IDs for these state owners are also reset by umount / mount. Note that each mount point gets a fresh nfs_server, so these structures are not retained across umount / mount. >> >> This means umount / mount with no lease expiry starts to re-play state owners with reset sequence IDs. Servers don't really care for that behavior. I have a test case that reliably gets a BAD_SEQID error from a server after a quick umount / mount followed by a single file creation. >> >> Now that we are about to switch to using more-or-less global SETCLIENTID boot verifiers, it seems to me that we really want a global openowner_id and lockowner_id as well. >> >> The performance impact of such a change might be acceptable because we cache and reuse state owners now. >> >> Thoughts? > > That's a definite server bug. If the client holds no open state, then it > is allowed to forget the open owner and start the sequence id from 0 > again. It is not required to remember sequence ids for open owners that > aren't in use. > > Our current client could easily trigger this bug even without a > umount/mount. The client is holding open state. Here's the exact reproducer on my modified client: 1. mount server:/export /mnt 2. touch /mnt/newfile 3. umount /mnt 4. mount server:/export /mnt 5. touch /mnt/newfile2 Step 5 causes the client to replay an open owner with a reset sequence ID, and the server replies BAD_SEQID. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 15:54 ` Chuck Lever @ 2012-04-12 15:58 ` Myklebust, Trond 2012-04-12 16:05 ` Chuck Lever 2012-04-12 17:07 ` J. Bruce Fields 0 siblings, 2 replies; 7+ messages in thread From: Myklebust, Trond @ 2012-04-12 15:58 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List T24gVGh1LCAyMDEyLTA0LTEyIGF0IDExOjU0IC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g T24gQXByIDEyLCAyMDEyLCBhdCAxMTo1MCBBTSwgTXlrbGVidXN0LCBUcm9uZCB3cm90ZToNCj4g DQo+ID4gT24gVGh1LCAyMDEyLTA0LTEyIGF0IDExOjQyIC0wNDAwLCBDaHVjayBMZXZlciB3cm90 ZToNCj4gPj4gSGktDQo+ID4+IA0KPiA+PiBDaGFuZ2luZyB0aGUgU0VUQ0xJRU5USUQgYm9vdCB2 ZXJpZmllciBzbyBpdCBpcyBnbG9iYWwgZm9yIHRoZSB3aG9sZSBjbGllbnQgZXhwb3NlcyBhIHBy b2JsZW0gd2l0aCBob3cgd2UgYWxsb2NhdGUgc3RhdGUgb3duZXJzLg0KPiA+PiANCj4gPj4gQSBx dWljayB1bW91bnQgLyBtb3VudCBzZXF1ZW5jZSBkZXN0cm95cyBhbGwgc3RhdGUgb24gdGhlIGNs aWVudC4gIEJ1dCBzaW5jZSB0aGUgY2xpZW50IG5vdyBhbHdheXMgdXNlcyB0aGUgc2FtZSBib290 IHZlcmlmaWVyIGFuZCBuZnNfY2xpZW50X2lkNCBzdHJpbmcsIHRoZSBzZXJ2ZXIgbm8gbG9uZ2Vy IHJlY29nbml6ZXMgYSBjbGllbnQgcmVib290LiAgRk9yIGEgZnJlc2ggbW91bnQsIHRoZSBjbGll bnQgbWF5IHBlcmZvcm0gYSBTRVRDTElFTlRJRCwgYnV0IGl0IGlzIHRyZWF0ZWQgYXMgYSBjYWxs YmFjayB1cGRhdGUgKHN0YXRlIGlzIG5vdCBwdXJnZWQpIGlmIHRoZSBjbGllbnQncyBsZWFzZSBo YXMgbm90IHlldCBleHBpcmVkLg0KPiA+PiANCj4gPj4gT3VyIHN0YXRlIG93bmVycyBhcmUgZ2Vu ZXJhdGVkIGZyb20gYSBwYWlyIG9mIGlkYSBzdHJ1Y3R1cmVzIGluIHRoZSBuZnNfc2VydmVyIGZv ciB0aGF0IG1vdW50LiAgVGhleSBhbHdheXMgc3RhcnQgZnJvbSB6ZXJvIGFmdGVyIGEgbW91bnQg b3BlcmF0aW9uLiAgTGlrZXdpc2UsIHRoZSBzZXF1ZW5jZSBJRHMgZm9yIHRoZXNlIHN0YXRlIG93 bmVycyBhcmUgYWxzbyByZXNldCBieSB1bW91bnQgLyBtb3VudC4gIE5vdGUgdGhhdCBlYWNoIG1v dW50IHBvaW50IGdldHMgYSBmcmVzaCBuZnNfc2VydmVyLCBzbyB0aGVzZSBzdHJ1Y3R1cmVzIGFy ZSBub3QgcmV0YWluZWQgYWNyb3NzIHVtb3VudCAvIG1vdW50Lg0KPiA+PiANCj4gPj4gVGhpcyBt ZWFucyB1bW91bnQgLyBtb3VudCB3aXRoIG5vIGxlYXNlIGV4cGlyeSBzdGFydHMgdG8gcmUtcGxh eSBzdGF0ZSBvd25lcnMgd2l0aCByZXNldCBzZXF1ZW5jZSBJRHMuICBTZXJ2ZXJzIGRvbid0IHJl YWxseSBjYXJlIGZvciB0aGF0IGJlaGF2aW9yLiAgSSBoYXZlIGEgdGVzdCBjYXNlIHRoYXQgcmVs aWFibHkgZ2V0cyBhIEJBRF9TRVFJRCBlcnJvciBmcm9tIGEgc2VydmVyIGFmdGVyIGEgcXVpY2sg dW1vdW50IC8gbW91bnQgZm9sbG93ZWQgYnkgYSBzaW5nbGUgZmlsZSBjcmVhdGlvbi4NCj4gPj4g DQo+ID4+IE5vdyB0aGF0IHdlIGFyZSBhYm91dCB0byBzd2l0Y2ggdG8gdXNpbmcgbW9yZS1vci1s ZXNzIGdsb2JhbCBTRVRDTElFTlRJRCBib290IHZlcmlmaWVycywgaXQgc2VlbXMgdG8gbWUgdGhh dCB3ZSByZWFsbHkgd2FudCBhIGdsb2JhbCBvcGVub3duZXJfaWQgYW5kIGxvY2tvd25lcl9pZCBh cyB3ZWxsLg0KPiA+PiANCj4gPj4gVGhlIHBlcmZvcm1hbmNlIGltcGFjdCBvZiBzdWNoIGEgY2hh bmdlIG1pZ2h0IGJlIGFjY2VwdGFibGUgYmVjYXVzZSB3ZSBjYWNoZSBhbmQgcmV1c2Ugc3RhdGUg b3duZXJzIG5vdy4NCj4gPj4gDQo+ID4+IFRob3VnaHRzPw0KPiA+IA0KPiA+IFRoYXQncyBhIGRl ZmluaXRlIHNlcnZlciBidWcuIElmIHRoZSBjbGllbnQgaG9sZHMgbm8gb3BlbiBzdGF0ZSwgdGhl biBpdA0KPiA+IGlzIGFsbG93ZWQgdG8gZm9yZ2V0IHRoZSBvcGVuIG93bmVyIGFuZCBzdGFydCB0 aGUgc2VxdWVuY2UgaWQgZnJvbSAwDQo+ID4gYWdhaW4uIEl0IGlzIG5vdCByZXF1aXJlZCB0byBy ZW1lbWJlciBzZXF1ZW5jZSBpZHMgZm9yIG9wZW4gb3duZXJzIHRoYXQNCj4gPiBhcmVuJ3QgaW4g dXNlLg0KPiA+IA0KPiA+IE91ciBjdXJyZW50IGNsaWVudCBjb3VsZCBlYXNpbHkgdHJpZ2dlciB0 aGlzIGJ1ZyBldmVuIHdpdGhvdXQgYQ0KPiA+IHVtb3VudC9tb3VudC4NCj4gDQo+IFRoZSBjbGll bnQgaXMgaG9sZGluZyBvcGVuIHN0YXRlLiAgSGVyZSdzIHRoZSBleGFjdCByZXByb2R1Y2VyIG9u IG15IG1vZGlmaWVkIGNsaWVudDoNCj4gDQo+IDEuICBtb3VudCBzZXJ2ZXI6L2V4cG9ydCAvbW50 DQo+IDIuICB0b3VjaCAvbW50L25ld2ZpbGUNCj4gMy4gIHVtb3VudCAvbW50DQo+IDQuICBtb3Vu dCBzZXJ2ZXI6L2V4cG9ydCAvbW50DQo+IDUuICB0b3VjaCAvbW50L25ld2ZpbGUyDQo+IA0KPiBT dGVwIDUgY2F1c2VzIHRoZSBjbGllbnQgdG8gcmVwbGF5IGFuIG9wZW4gb3duZXIgd2l0aCBhIHJl c2V0IHNlcXVlbmNlIElELCBhbmQgdGhlIHNlcnZlciByZXBsaWVzIEJBRF9TRVFJRC4NCg0KdG91 Y2ggd29uJ3Qga2VlcCB0aGUgZmlsZSBvcGVuLiBUaGVyZSBpcyBubyBvcGVuIHN0YXRlIG9uY2Ug dG91Y2ggaGFzDQpmaW5pc2hlZCBleGVjdXRpbmcuDQoNCldoYXQgeW91IGhhdmUgZXhwb3NlZCBh Ym92ZSBpcyBhIF9zZXJ2ZXJfIGJ1Zy4gVGhlIHNlcnZlciBpcyBfbm90Xw0KYWxsb3dlZCB0byBh c3N1bWUgdGhhdCB0aGUgY2xpZW50IHdpbGwgY2FjaGUgYW4gb3BlbiBvd25lciBmb3JldmVyIG9u Y2UNCml0IG5vIGxvbmdlciBob2xkcyBhbnkgb3BlbiBzdGF0ZSB1c2luZyB0aGF0IG9wZW4gb3du ZXIuIFdlIGhhZCBhIGxvb25nDQpkaXNjdXNzaW9uIGFib3V0IHRoaXMgb24gdGhlIG1haWxpbmcg bGlzdCBhIGZldyB5ZWFycyBhZ28gd2l0aCBEYXZpZA0KUm9iaW5zb24gYmVpbmcgdGhlIHBlcnNv biB3aG8gZm9ybXVsYXRlZCB0aGUgYWJvdmUgcnVsZS4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QN CkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBu ZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo= ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 15:58 ` Myklebust, Trond @ 2012-04-12 16:05 ` Chuck Lever 2012-04-12 17:32 ` Myklebust, Trond 2012-04-12 17:07 ` J. Bruce Fields 1 sibling, 1 reply; 7+ messages in thread From: Chuck Lever @ 2012-04-12 16:05 UTC (permalink / raw) To: Myklebust, Trond; +Cc: Linux NFS Mailing List On Apr 12, 2012, at 11:58 AM, Myklebust, Trond wrote: > On Thu, 2012-04-12 at 11:54 -0400, Chuck Lever wrote: >> On Apr 12, 2012, at 11:50 AM, Myklebust, Trond wrote: >> >>> On Thu, 2012-04-12 at 11:42 -0400, Chuck Lever wrote: >>>> Hi- >>>> >>>> Changing the SETCLIENTID boot verifier so it is global for the whole client exposes a problem with how we allocate state owners. >>>> >>>> A quick umount / mount sequence destroys all state on the client. But since the client now always uses the same boot verifier and nfs_client_id4 string, the server no longer recognizes a client reboot. FOr a fresh mount, the client may perform a SETCLIENTID, but it is treated as a callback update (state is not purged) if the client's lease has not yet expired. >>>> >>>> Our state owners are generated from a pair of ida structures in the nfs_server for that mount. They always start from zero after a mount operation. Likewise, the sequence IDs for these state owners are also reset by umount / mount. Note that each mount point gets a fresh nfs_server, so these structures are not retained across umount / mount. >>>> >>>> This means umount / mount with no lease expiry starts to re-play state owners with reset sequence IDs. Servers don't really care for that behavior. I have a test case that reliably gets a BAD_SEQID error from a server after a quick umount / mount followed by a single file creation. >>>> >>>> Now that we are about to switch to using more-or-less global SETCLIENTID boot verifiers, it seems to me that we really want a global openowner_id and lockowner_id as well. >>>> >>>> The performance impact of such a change might be acceptable because we cache and reuse state owners now. >>>> >>>> Thoughts? >>> >>> That's a definite server bug. If the client holds no open state, then it >>> is allowed to forget the open owner and start the sequence id from 0 >>> again. It is not required to remember sequence ids for open owners that >>> aren't in use. >>> >>> Our current client could easily trigger this bug even without a >>> umount/mount. >> >> The client is holding open state. Here's the exact reproducer on my modified client: >> >> 1. mount server:/export /mnt >> 2. touch /mnt/newfile >> 3. umount /mnt >> 4. mount server:/export /mnt >> 5. touch /mnt/newfile2 >> >> Step 5 causes the client to replay an open owner with a reset sequence ID, and the server replies BAD_SEQID. > > touch won't keep the file open. There is no open state once touch has > finished executing. OK, agreed. > What you have exposed above is a _server_ bug. The server is _not_ > allowed to assume that the client will cache an open owner forever once > it no longer holds any open state using that open owner. We had a loong > discussion about this on the mailing list a few years ago with David > Robinson being the person who formulated the above rule. I'm not sure I would characterize this as a server bug just yet. On OPEN, the server is allowed to tell the client it is using a bad sequence ID, and the client is supposed to recover by trying again with a different OO. Our BAD_SEQID recovery logic appears to be broken, because our client goes into a loop retrying the OPEN with the same OO. If recovery worked, this would all be perfectly transparent, I think. I was taking a step back and wondering how the client chose the OO in the first place. But you claimed above that our client could trigger this bug without a umount / mount sequence. Do you have an example of how I might try that? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 16:05 ` Chuck Lever @ 2012-04-12 17:32 ` Myklebust, Trond 0 siblings, 0 replies; 7+ messages in thread From: Myklebust, Trond @ 2012-04-12 17:32 UTC (permalink / raw) To: Chuck Lever; +Cc: Linux NFS Mailing List T24gVGh1LCAyMDEyLTA0LTEyIGF0IDEyOjA1IC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZToNCj4g T24gQXByIDEyLCAyMDEyLCBhdCAxMTo1OCBBTSwgTXlrbGVidXN0LCBUcm9uZCB3cm90ZToNCj4g DQo+ID4gT24gVGh1LCAyMDEyLTA0LTEyIGF0IDExOjU0IC0wNDAwLCBDaHVjayBMZXZlciB3cm90 ZToNCj4gPj4gT24gQXByIDEyLCAyMDEyLCBhdCAxMTo1MCBBTSwgTXlrbGVidXN0LCBUcm9uZCB3 cm90ZToNCj4gPj4gDQo+ID4+PiBPbiBUaHUsIDIwMTItMDQtMTIgYXQgMTE6NDIgLTA0MDAsIENo dWNrIExldmVyIHdyb3RlOg0KPiA+Pj4+IEhpLQ0KPiA+Pj4+IA0KPiA+Pj4+IENoYW5naW5nIHRo ZSBTRVRDTElFTlRJRCBib290IHZlcmlmaWVyIHNvIGl0IGlzIGdsb2JhbCBmb3IgdGhlIHdob2xl IGNsaWVudCBleHBvc2VzIGEgcHJvYmxlbSB3aXRoIGhvdyB3ZSBhbGxvY2F0ZSBzdGF0ZSBvd25l cnMuDQo+ID4+Pj4gDQo+ID4+Pj4gQSBxdWljayB1bW91bnQgLyBtb3VudCBzZXF1ZW5jZSBkZXN0 cm95cyBhbGwgc3RhdGUgb24gdGhlIGNsaWVudC4gIEJ1dCBzaW5jZSB0aGUgY2xpZW50IG5vdyBh bHdheXMgdXNlcyB0aGUgc2FtZSBib290IHZlcmlmaWVyIGFuZCBuZnNfY2xpZW50X2lkNCBzdHJp bmcsIHRoZSBzZXJ2ZXIgbm8gbG9uZ2VyIHJlY29nbml6ZXMgYSBjbGllbnQgcmVib290LiAgRk9y IGEgZnJlc2ggbW91bnQsIHRoZSBjbGllbnQgbWF5IHBlcmZvcm0gYSBTRVRDTElFTlRJRCwgYnV0 IGl0IGlzIHRyZWF0ZWQgYXMgYSBjYWxsYmFjayB1cGRhdGUgKHN0YXRlIGlzIG5vdCBwdXJnZWQp IGlmIHRoZSBjbGllbnQncyBsZWFzZSBoYXMgbm90IHlldCBleHBpcmVkLg0KPiA+Pj4+IA0KPiA+ Pj4+IE91ciBzdGF0ZSBvd25lcnMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgcGFpciBvZiBpZGEgc3Ry dWN0dXJlcyBpbiB0aGUgbmZzX3NlcnZlciBmb3IgdGhhdCBtb3VudC4gIFRoZXkgYWx3YXlzIHN0 YXJ0IGZyb20gemVybyBhZnRlciBhIG1vdW50IG9wZXJhdGlvbi4gIExpa2V3aXNlLCB0aGUgc2Vx dWVuY2UgSURzIGZvciB0aGVzZSBzdGF0ZSBvd25lcnMgYXJlIGFsc28gcmVzZXQgYnkgdW1vdW50 IC8gbW91bnQuICBOb3RlIHRoYXQgZWFjaCBtb3VudCBwb2ludCBnZXRzIGEgZnJlc2ggbmZzX3Nl cnZlciwgc28gdGhlc2Ugc3RydWN0dXJlcyBhcmUgbm90IHJldGFpbmVkIGFjcm9zcyB1bW91bnQg LyBtb3VudC4NCj4gPj4+PiANCj4gPj4+PiBUaGlzIG1lYW5zIHVtb3VudCAvIG1vdW50IHdpdGgg bm8gbGVhc2UgZXhwaXJ5IHN0YXJ0cyB0byByZS1wbGF5IHN0YXRlIG93bmVycyB3aXRoIHJlc2V0 IHNlcXVlbmNlIElEcy4gIFNlcnZlcnMgZG9uJ3QgcmVhbGx5IGNhcmUgZm9yIHRoYXQgYmVoYXZp b3IuICBJIGhhdmUgYSB0ZXN0IGNhc2UgdGhhdCByZWxpYWJseSBnZXRzIGEgQkFEX1NFUUlEIGVy cm9yIGZyb20gYSBzZXJ2ZXIgYWZ0ZXIgYSBxdWljayB1bW91bnQgLyBtb3VudCBmb2xsb3dlZCBi eSBhIHNpbmdsZSBmaWxlIGNyZWF0aW9uLg0KPiA+Pj4+IA0KPiA+Pj4+IE5vdyB0aGF0IHdlIGFy ZSBhYm91dCB0byBzd2l0Y2ggdG8gdXNpbmcgbW9yZS1vci1sZXNzIGdsb2JhbCBTRVRDTElFTlRJ RCBib290IHZlcmlmaWVycywgaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSByZWFsbHkgd2FudCBhIGds b2JhbCBvcGVub3duZXJfaWQgYW5kIGxvY2tvd25lcl9pZCBhcyB3ZWxsLg0KPiA+Pj4+IA0KPiA+ Pj4+IFRoZSBwZXJmb3JtYW5jZSBpbXBhY3Qgb2Ygc3VjaCBhIGNoYW5nZSBtaWdodCBiZSBhY2Nl cHRhYmxlIGJlY2F1c2Ugd2UgY2FjaGUgYW5kIHJldXNlIHN0YXRlIG93bmVycyBub3cuDQo+ID4+ Pj4gDQo+ID4+Pj4gVGhvdWdodHM/DQo+ID4+PiANCj4gPj4+IFRoYXQncyBhIGRlZmluaXRlIHNl cnZlciBidWcuIElmIHRoZSBjbGllbnQgaG9sZHMgbm8gb3BlbiBzdGF0ZSwgdGhlbiBpdA0KPiA+ Pj4gaXMgYWxsb3dlZCB0byBmb3JnZXQgdGhlIG9wZW4gb3duZXIgYW5kIHN0YXJ0IHRoZSBzZXF1 ZW5jZSBpZCBmcm9tIDANCj4gPj4+IGFnYWluLiBJdCBpcyBub3QgcmVxdWlyZWQgdG8gcmVtZW1i ZXIgc2VxdWVuY2UgaWRzIGZvciBvcGVuIG93bmVycyB0aGF0DQo+ID4+PiBhcmVuJ3QgaW4gdXNl Lg0KPiA+Pj4gDQo+ID4+PiBPdXIgY3VycmVudCBjbGllbnQgY291bGQgZWFzaWx5IHRyaWdnZXIg dGhpcyBidWcgZXZlbiB3aXRob3V0IGENCj4gPj4+IHVtb3VudC9tb3VudC4NCj4gPj4gDQo+ID4+ IFRoZSBjbGllbnQgaXMgaG9sZGluZyBvcGVuIHN0YXRlLiAgSGVyZSdzIHRoZSBleGFjdCByZXBy b2R1Y2VyIG9uIG15IG1vZGlmaWVkIGNsaWVudDoNCj4gPj4gDQo+ID4+IDEuICBtb3VudCBzZXJ2 ZXI6L2V4cG9ydCAvbW50DQo+ID4+IDIuICB0b3VjaCAvbW50L25ld2ZpbGUNCj4gPj4gMy4gIHVt b3VudCAvbW50DQo+ID4+IDQuICBtb3VudCBzZXJ2ZXI6L2V4cG9ydCAvbW50DQo+ID4+IDUuICB0 b3VjaCAvbW50L25ld2ZpbGUyDQo+ID4+IA0KPiA+PiBTdGVwIDUgY2F1c2VzIHRoZSBjbGllbnQg dG8gcmVwbGF5IGFuIG9wZW4gb3duZXIgd2l0aCBhIHJlc2V0IHNlcXVlbmNlIElELCBhbmQgdGhl IHNlcnZlciByZXBsaWVzIEJBRF9TRVFJRC4NCj4gPiANCj4gPiB0b3VjaCB3b24ndCBrZWVwIHRo ZSBmaWxlIG9wZW4uIFRoZXJlIGlzIG5vIG9wZW4gc3RhdGUgb25jZSB0b3VjaCBoYXMNCj4gPiBm aW5pc2hlZCBleGVjdXRpbmcuDQo+IA0KPiBPSywgYWdyZWVkLg0KPiANCj4gPiBXaGF0IHlvdSBo YXZlIGV4cG9zZWQgYWJvdmUgaXMgYSBfc2VydmVyXyBidWcuIFRoZSBzZXJ2ZXIgaXMgX25vdF8N Cj4gPiBhbGxvd2VkIHRvIGFzc3VtZSB0aGF0IHRoZSBjbGllbnQgd2lsbCBjYWNoZSBhbiBvcGVu IG93bmVyIGZvcmV2ZXIgb25jZQ0KPiA+IGl0IG5vIGxvbmdlciBob2xkcyBhbnkgb3BlbiBzdGF0 ZSB1c2luZyB0aGF0IG9wZW4gb3duZXIuIFdlIGhhZCBhIGxvb25nDQo+ID4gZGlzY3Vzc2lvbiBh Ym91dCB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QgYSBmZXcgeWVhcnMgYWdvIHdpdGggRGF2aWQN Cj4gPiBSb2JpbnNvbiBiZWluZyB0aGUgcGVyc29uIHdobyBmb3JtdWxhdGVkIHRoZSBhYm92ZSBy dWxlLg0KPiANCj4gSSdtIG5vdCBzdXJlIEkgd291bGQgY2hhcmFjdGVyaXplIHRoaXMgYXMgYSBz ZXJ2ZXIgYnVnIGp1c3QgeWV0LiAgT24gT1BFTiwgdGhlIHNlcnZlciBpcyBhbGxvd2VkIHRvIHRl bGwgdGhlIGNsaWVudCBpdCBpcyB1c2luZyBhIGJhZCBzZXF1ZW5jZSBJRCwgYW5kIHRoZSBjbGll bnQgaXMgc3VwcG9zZWQgdG8gcmVjb3ZlciBieSB0cnlpbmcgYWdhaW4gd2l0aCBhIGRpZmZlcmVu dCBPTy4gIE91ciBCQURfU0VRSUQgcmVjb3ZlcnkgbG9naWMgYXBwZWFycyB0byBiZSBicm9rZW4s IGJlY2F1c2Ugb3VyIGNsaWVudCBnb2VzIGludG8gYSBsb29wIHJldHJ5aW5nIHRoZSBPUEVOIHdp dGggdGhlIHNhbWUgT08uICBJZiByZWNvdmVyeSB3b3JrZWQsIHRoaXMgd291bGQgYWxsIGJlIHBl cmZlY3RseSB0cmFuc3BhcmVudCwgSSB0aGluay4NCg0KQWZ0ZXIgcmUtcmVhZGluZyB0aGUgdGhy ZWFkIG9uDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmZzdjQvY3VycmVu dC9tc2cwMTcxOS5odG1sIEknbQ0KaGF2aW5nIHNlY29uZCB0aG91Z2h0cy4gSSBkaWQgcmVtZW1i ZXIgYmVpbmcgY29udmluY2VkIGJ5IERhdmlkJ3MNCmFyZ3VtZW50cywgYnV0IGxvb2tpbmcgYmFj ayBpdCBkb2VzIG5vdCBhcHBlYXIgdGhhdCB3ZSBhY2hpZXZlZA0KY29uc2Vuc3VzLg0KDQpUaGUg d2hvbGUgcHJvYmxlbSBpbiB0aGUgc3BlYyBpcyB0aGF0IGFsdGhvdWdoIHRoZSBzZXJ2ZXIgaXMg YWxsb3dlZCB0bw0KZm9yZ2V0IHRoZSBvcGVuIG93bmVyIHdoZW4gdGhlIGNsaWVudCBubyBsb25n ZXIgaG9sZHMgYW55IHN0YXRlLCBpdCBpcw0Kbm90IF9yZXF1aXJlZF8gdG8gZG8gc28uDQpJbiBv dGhlciB3b3JkcywgdGhlIGNsaWVudCBuZWVkcyB0byBiZSBwcmVwYXJlZCBmb3IgZWl0aGVyIEJB RF9TRVFJRCBvcg0KYW4gT1BFTl9DT05GSVJNIHJlcXVlc3QgaWYgaXQgdHJpZXMgdG8gT1BFTiB1 c2luZyBhIHJlY3ljbGVkIG9wZW4gb3duZXIuDQoNCj4gSSB3YXMgdGFraW5nIGEgc3RlcCBiYWNr IGFuZCB3b25kZXJpbmcgaG93IHRoZSBjbGllbnQgY2hvc2UgdGhlIE9PIGluIHRoZSBmaXJzdCBw bGFjZS4NCj4gDQo+IEJ1dCB5b3UgY2xhaW1lZCBhYm92ZSB0aGF0IG91ciBjbGllbnQgY291bGQg dHJpZ2dlciB0aGlzIGJ1ZyB3aXRob3V0IGEgdW1vdW50IC8gbW91bnQgc2VxdWVuY2UuICBEbyB5 b3UgaGF2ZSBhbiBleGFtcGxlIG9mIGhvdyBJIG1pZ2h0IHRyeSB0aGF0Pw0KDQpUaGUgbGF0ZXN0 IGNsaWVudCB1c2VzIHRoZSBpZGEgYWxsb2NhdG9yIGluIG9yZGVyIHRvIGdlbmVyYXRlIHVuaXF1 ZQ0KaWRlbnRpZmllcnMuIFRoYXQgcGFydGljdWxhciBhbGxvY2F0b3Igb2ZmZXJzIG5vIGd1YXJh bnRlZXMgdGhhdCBpdA0Kd29uJ3QgcmUtdXNlIGFuIGlkZW50aWZpZXIgdGhhdCBpcyBubyBsb25n ZXIgaW4gdXNlLiBJbiBmYWN0LCBiZWNhdXNlIGl0DQp1c2VzIGZpbmRfbmV4dF96ZXJvX2JpdCgp LCByZXVzZSBpcyBhY3R1YWxseSB0aGUgbm9ybS4NCg0KU28gSSBiZWxpZXZlIHRoYXQgYWxsIHlv dSBuZWVkIHRvIGRvIGhlcmUgaXMgY3JlYXRlIDIgb3BlbiBvd25lcnMgdXNpbmcNCnNpbXVsdGVu ZW91cyAnb3BlbigpJyBjYWxscyBmcm9tIDIgcHJvY2Vzc2VzIHdpdGggZGlmZmVyZW50IGNyZWRl bnRpYWxzLA0KdGhlbiBjbG9zZSBib3RoIGZpbGUgZGVzY3JpcHRvcnMsIHdhaXQgMSBsZWFzZSBw ZXJpb2QsIGFuZCB0aGVuIHRyeQ0KJ29wZW4oKScgZnJvbSBib3RoIHByb2Nlc3NlcyBhZ2Fpbi4N CkFzIGZhciBhcyBJIGNhbiBzZWUsIHRoZSBnYXJiYWdlIGNvbGxlY3RvciBzaG91bGQgdGhyb3cg b3V0IHRoZSBzZWNvbmQNCm9wZW4gb3duZXIgd2hlbiB5b3UgZG8gdGhlIHRoaXJkICdvcGVuKCkn LCBhbmQgc28gdGhlIGNsaWVudCB3aWxsDQpnZW5lcmF0ZSBhIG5ldyBvbmUgd2l0aCB0aGUgc2Ft ZSBpZGEgdmFsdWUgd2hlbiB5b3UgZG8gdGhlIGZvdXJ0aA0Kb3BlbigpLg0KDQotLSANClRyb25k IE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQu TXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg== ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: global openowner_id and lockowner_id 2012-04-12 15:58 ` Myklebust, Trond 2012-04-12 16:05 ` Chuck Lever @ 2012-04-12 17:07 ` J. Bruce Fields 1 sibling, 0 replies; 7+ messages in thread From: J. Bruce Fields @ 2012-04-12 17:07 UTC (permalink / raw) To: Myklebust, Trond; +Cc: Chuck Lever, Linux NFS Mailing List On Thu, Apr 12, 2012 at 03:58:45PM +0000, Myklebust, Trond wrote: > touch won't keep the file open. There is no open state once touch has > finished executing. > > What you have exposed above is a _server_ bug. The server is _not_ > allowed to assume that the client will cache an open owner forever once > it no longer holds any open state using that open owner. We had a loong > discussion about this on the mailing list a few years ago with David > Robinson being the person who formulated the above rule. Chuck, what server are you testing against? I don't think the Linux server does the above, so it probably does need fixing. --b. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-04-12 17:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-12 15:42 global openowner_id and lockowner_id Chuck Lever 2012-04-12 15:50 ` Myklebust, Trond 2012-04-12 15:54 ` Chuck Lever 2012-04-12 15:58 ` Myklebust, Trond 2012-04-12 16:05 ` Chuck Lever 2012-04-12 17:32 ` Myklebust, Trond 2012-04-12 17:07 ` J. Bruce Fields
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.