diff for duplicates of <1485193333.34422.5.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index ea9d03d..d6dac0b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,20 +1,31 @@ -T24gTW9uLCAyMDE3LTAxLTIzIGF0IDE4OjM4ICswMTAwLCBoY2ggd3JvdGU6DQo+IE9uIE1vbiwg -SmFuIDIzLCAyMDE3IGF0IDA1OjI1OjM0UE0gKzAwMDAsIFRyb25kIE15a2xlYnVzdCB3cm90ZToN -Cj4gPiBJbiB0aGF0IGNhc2UgdGhlIGNsaWVudCB3aWxsIGJlIHJlcXVpcmVkIHRvIGNvbnRpbnVl -IHRvIG5lZWQgdG8NCj4gPiBzZW5kDQo+ID4gbXRpbWUvY3RpbWUgaW4gb3JkZXIgdG8gZW5zdXJl -IHRoYXQgd2UgZ2V0IHRoZSBzYW1lIGhpc3RvcmljYWwNCj4gPiBzZW1hbnRpY3Mgdy5yLnQuIGZ0 -cnVuY2F0ZSgpIHZzIHRydW5jYXRlKCkuDQo+ID4gDQo+ID4gSU9XOiBJdCdzIG5vdCBhIHF1ZXN0 -aW9uIG9mIHRoZSBjbGllbnQgYmVpbmcgbGF6eSBhYm91dCBjbGVhcmluZw0KPiA+IHRoZQ0KPiA+ -IGZsYWdzLiBJdCdzIGEgcXVlc3Rpb24gb2YgZW5mb3JjaW5nIHRoZSBjb3JyZWN0IHNlbWFudGlj -cy4NCj4gDQo+IE5vLCB0aGUgTkZTIHNwZWMgcmVxdWlyZXMgdGhlIHNlcnZlciB0byBhZGQgYW4g -aW1wbGljaXQgbXRpbWUNCj4gd2hlbiB0aGUgc2l6ZSBhY3R1YWxseSBjaGFuZ2VzLsKgwqBJbiBm -YWN0IHRoZSBjdXJyZW50IGNvZGUgaGFzIGENCj4gY29tbWVudA0KPiBwb2ludGluZyB0byB0aGUg -c2VjdGlvbjoNCj4gDQo+IMKgKiBSRkM1NjYxLCBTZWN0aW9uIDE4LjMwLjQ6DQo+IMKgKsKgwqDC -oENoYW5naW5nIHRoZSBzaXplIG9mIGEgZmlsZSB3aXRoIFNFVEFUVFIgaW5kaXJlY3RseQ0KPiDC -oCrCoMKgwqBjaGFuZ2VzIHRoZSB0aW1lX21vZGlmeSBhbmQgY2hhbmdlIGF0dHJpYnV0ZXMuDQo+ -IMKgKg0KPiDCoCogKGFuZCBzaW1pbGFyIGZvciB0aGUgb2xkZXIgUkZDcykNCj4gDQo+IEFuZCB5 -ZXMsIEkndmUgZG91YmxlIGNoZWNrZWQgdGhhdCBpbiB0aGUgUkZDLg0KDQpTdXJlLCBidXQgdHJ1 -bmNhdGUoKSBvbiBQT1NJWCBhZGRzIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBtdGltZS9jdGlt -ZQ0Kc2hvdWxkIGNoYW5nZSBldmVuIHdoZW4gdGhlIGZpbGUgc2l6ZSBpcyBub3QgY2hhbmdlZC4N -Cg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJp -bWFyeURhdGENCnRyb25kLm15a2xlYnVzdEBwcmltYXJ5ZGF0YS5jb20NCg== +On Mon, 2017-01-23 at 18:38 +0100, hch wrote: +> On Mon, Jan 23, 2017 at 05:25:34PM +0000, Trond Myklebust wrote: +> > In that case the client will be required to continue to need to +> > send +> > mtime/ctime in order to ensure that we get the same historical +> > semantics w.r.t. ftruncate() vs truncate(). +> > +> > IOW: It's not a question of the client being lazy about clearing +> > the +> > flags. It's a question of enforcing the correct semantics. +> +> No, the NFS spec requires the server to add an implicit mtime +> when the size actually changes. In fact the current code has a +> comment +> pointing to the section: +> +> * RFC5661, Section 18.30.4: +> * Changing the size of a file with SETATTR indirectly +> * changes the time_modify and change attributes. +> * +> * (and similar for the older RFCs) +> +> And yes, I've double checked that in the RFC. + +Sure, but truncate() on POSIX adds the requirement that the mtime/ctime +should change even when the file size is not changed. + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index 2fc20c3..c085c1f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,25 +19,36 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gTW9uLCAyMDE3LTAxLTIzIGF0IDE4OjM4ICswMTAwLCBoY2ggd3JvdGU6DQo+IE9uIE1vbiwg\n" - "SmFuIDIzLCAyMDE3IGF0IDA1OjI1OjM0UE0gKzAwMDAsIFRyb25kIE15a2xlYnVzdCB3cm90ZToN\n" - "Cj4gPiBJbiB0aGF0IGNhc2UgdGhlIGNsaWVudCB3aWxsIGJlIHJlcXVpcmVkIHRvIGNvbnRpbnVl\n" - "IHRvIG5lZWQgdG8NCj4gPiBzZW5kDQo+ID4gbXRpbWUvY3RpbWUgaW4gb3JkZXIgdG8gZW5zdXJl\n" - "IHRoYXQgd2UgZ2V0IHRoZSBzYW1lIGhpc3RvcmljYWwNCj4gPiBzZW1hbnRpY3Mgdy5yLnQuIGZ0\n" - "cnVuY2F0ZSgpIHZzIHRydW5jYXRlKCkuDQo+ID4gDQo+ID4gSU9XOiBJdCdzIG5vdCBhIHF1ZXN0\n" - "aW9uIG9mIHRoZSBjbGllbnQgYmVpbmcgbGF6eSBhYm91dCBjbGVhcmluZw0KPiA+IHRoZQ0KPiA+\n" - "IGZsYWdzLiBJdCdzIGEgcXVlc3Rpb24gb2YgZW5mb3JjaW5nIHRoZSBjb3JyZWN0IHNlbWFudGlj\n" - "cy4NCj4gDQo+IE5vLCB0aGUgTkZTIHNwZWMgcmVxdWlyZXMgdGhlIHNlcnZlciB0byBhZGQgYW4g\n" - "aW1wbGljaXQgbXRpbWUNCj4gd2hlbiB0aGUgc2l6ZSBhY3R1YWxseSBjaGFuZ2VzLsKgwqBJbiBm\n" - "YWN0IHRoZSBjdXJyZW50IGNvZGUgaGFzIGENCj4gY29tbWVudA0KPiBwb2ludGluZyB0byB0aGUg\n" - "c2VjdGlvbjoNCj4gDQo+IMKgKiBSRkM1NjYxLCBTZWN0aW9uIDE4LjMwLjQ6DQo+IMKgKsKgwqDC\n" - "oENoYW5naW5nIHRoZSBzaXplIG9mIGEgZmlsZSB3aXRoIFNFVEFUVFIgaW5kaXJlY3RseQ0KPiDC\n" - "oCrCoMKgwqBjaGFuZ2VzIHRoZSB0aW1lX21vZGlmeSBhbmQgY2hhbmdlIGF0dHJpYnV0ZXMuDQo+\n" - "IMKgKg0KPiDCoCogKGFuZCBzaW1pbGFyIGZvciB0aGUgb2xkZXIgUkZDcykNCj4gDQo+IEFuZCB5\n" - "ZXMsIEkndmUgZG91YmxlIGNoZWNrZWQgdGhhdCBpbiB0aGUgUkZDLg0KDQpTdXJlLCBidXQgdHJ1\n" - "bmNhdGUoKSBvbiBQT1NJWCBhZGRzIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBtdGltZS9jdGlt\n" - "ZQ0Kc2hvdWxkIGNoYW5nZSBldmVuIHdoZW4gdGhlIGZpbGUgc2l6ZSBpcyBub3QgY2hhbmdlZC4N\n" - "Cg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJp\n" - bWFyeURhdGENCnRyb25kLm15a2xlYnVzdEBwcmltYXJ5ZGF0YS5jb20NCg== + "On Mon, 2017-01-23 at 18:38 +0100, hch wrote:\n" + "> On Mon, Jan 23, 2017 at 05:25:34PM +0000, Trond Myklebust wrote:\n" + "> > In that case the client will be required to continue to need to\n" + "> > send\n" + "> > mtime/ctime in order to ensure that we get the same historical\n" + "> > semantics w.r.t. ftruncate() vs truncate().\n" + "> > \n" + "> > IOW: It's not a question of the client being lazy about clearing\n" + "> > the\n" + "> > flags. It's a question of enforcing the correct semantics.\n" + "> \n" + "> No, the NFS spec requires the server to add an implicit mtime\n" + "> when the size actually changes.\302\240\302\240In fact the current code has a\n" + "> comment\n" + "> pointing to the section:\n" + "> \n" + "> \302\240* RFC5661, Section 18.30.4:\n" + "> \302\240*\302\240\302\240\302\240Changing the size of a file with SETATTR indirectly\n" + "> \302\240*\302\240\302\240\302\240changes the time_modify and change attributes.\n" + "> \302\240*\n" + "> \302\240* (and similar for the older RFCs)\n" + "> \n" + "> And yes, I've double checked that in the RFC.\n" + "\n" + "Sure, but truncate() on POSIX adds the requirement that the mtime/ctime\n" + "should change even when the file size is not changed.\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -4f37ddc0d26470c9e52749fcb6425bc8b96e6947f10da551bfd25f9e4a6a2c1e +694d4ca504ea016f3b1b869edb5d966f4dd671ff655f93437a2bffa4f2810053
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.