* 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 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
* 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
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.