diff for duplicates of <1489004308.3098.10.camel@primarydata.com> diff --git a/a/1.txt b/N1/1.txt index 1be23e2..5d00431 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,45 +1,70 @@ -T24gV2VkLCAyMDE3LTAzLTA4IGF0IDE1OjAwIC0wNTAwLCBPbGdhIEtvcm5pZXZza2FpYSB3cm90 -ZToNCj4gPiBPbiBNYXIgOCwgMjAxNywgYXQgMjo1MyBQTSwgSi4gQnJ1Y2UgRmllbGRzIDxiZmll -bGRzQGZpZWxkc2VzLm9yZz4NCj4gPiB3cm90ZToNCj4gPiANCj4gPiBPbiBXZWQsIE1hciAwOCwg -MjAxNyBhdCAxMjozMjoxMlBNIC0wNTAwLCBPbGdhIEtvcm5pZXZza2FpYSB3cm90ZToNCj4gPiA+ -IA0KPiA+ID4gPiBPbiBNYXIgOCwgMjAxNywgYXQgMTI6MjUgUE0sIENocmlzdG9waCBIZWxsd2ln -IDxoY2hAaW5mcmFkZWFkLm8NCj4gPiA+ID4gcmc+DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiAN -Cj4gPiA+ID4gT24gV2VkLCBNYXIgMDgsIDIwMTcgYXQgMTI6MDU6MjFQTSAtMDUwMCwgSi4gQnJ1 -Y2UgRmllbGRzDQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+IFNpbmNlIGNvcHkgaXNuJ3QgYXRv -bWljIHRoYXQgY2hlY2sgaXMgbmV2ZXIgZ29pbmcgdG8gYmUNCj4gPiA+ID4gPiByZWxpYWJsZS4N -Cj4gPiA+ID4gDQo+ID4gPiA+IFRoYXQncyB0cnVlIGZvciBldmVyeXRoaW5nIHRoYXQgQ09QWSBk -b2VzLsKgwqBCeSB0aGF0IGxvZ2ljIHdlDQo+ID4gPiA+IHNob3VsZA0KPiA+ID4gPiBub3QgaW1w -bGVtZW50IGl0IGF0IGFsbCAoYSBsb2dpYyB0aGF0IEknZCBmdWxseSBzdXBwb3J0KQ0KPiA+ID4g -DQo+ID4gPiBJZiB5b3Ugd2VyZSB0byBvbmx5IGtlZXAgQ0xPTkUgdGhlbiB5b3XigJlkIGxvc2Ug -YSBodWdlIHBlcmZvcm1hbmNlDQo+ID4gPiBnYWluDQo+ID4gPiB5b3UgZ2V0IGZyb20gc2VydmVy -LXRvLXNlcnZlciBDT1BZLsKgDQo+ID4gDQo+ID4gWWVzLsKgwqBBbHNvLCBJIHRoaW5rIGNvcHkt -bGlrZSBjb3B5IGltcGxlbWVudGF0aW9ucyBoYXZlIHJlYXNvbmFibGUNCj4gPiBzZW1hbnRpY3Mg -dGhhdCBhcmUgYmFzaWNhbGx5IHRoZSBzYW1lIGFzIHJlYWQ6DQo+ID4gDQo+ID4gCS0gY29weSBj -YW4gcmV0dXJuIHN1Y2Nlc3NmdWxseSB3aXRoIGxlc3MgY29waWVkIHRoYW4gcmVxdWVzdGVkLg0K -PiA+IAktIGl0J3MgZmluZSBmb3IgdGhlIGNvcGllZCByYW5nZSB0byBzdGFydCBhbmQvb3IgZW5k -IHBhc3QgZW5kDQo+ID4gb2YNCj4gPiAJwqDCoGZpbGUsIGl0J2xsIGp1c3QgcmV0dXJuIGEgc2hv -cnQgcmVhZC4NCj4gPiAJLSBBIGNvcHkgb2YgbW9yZSB0aGFuIDAgYnl0ZXMgcmV0dXJuaW5nIDAg -bWVhbnMgeW91J3JlIGF0IGVuZA0KPiA+IG9mDQo+ID4gCcKgwqBmaWxlLg0KPiA+IA0KPiA+IFRo -ZSBwYXJ0aWN1bGFyIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoYXQgZG9lc24ndCBmaXQgaG93IGNs -b25lDQo+ID4gd29ya3MgYXQNCj4gPiBhbGwuDQo+ID4gDQo+ID4gSXQgZmVlbHMgbGlrZSB3aGF0 -IGhhcHBlbmVkIGlzIHRoYXQgY29weV9maWxlX3JhbmdlKCkgd2FzIG1hZGUNCj4gPiBtYWlubHkN -Cj4gPiBmb3IgdGhlIGNsb25lIGNhc2UsIHdpdGggdGhlIGlkZWEgdGhhdCBjb3B5IG1pZ2h0IGJl -IHJlbHVjdGFudGx5DQo+ID4gYWNjZXB0ZWQgYXMgYSBzZWNvbmQtY2xhc3MgaW1wbGVtZW50YXRp -b24uDQoNCkhpc3RvcmljYWxseT8gTm8uLi4gQ2hyaXN0b3BoIGFkZGVkIGNsb25lIGFzIGEgdmFs -aWQgaW1wbGVtZW50YXRpb24gb2YNCmNvcHlfZmlsZV9yYW5nZSgpIGFsbW9zdCBhIHllYXIgYWZ0 -ZXIgWmFjaCBhbmQgQW5uYSBkZWZpbmVkIHRoZQ0Kc2VtYW50aWNzIG9mIHZmc19jb3B5X2ZpbGVf -cmFuZ2UoKS4gZ2l0IGJsYW1lIGlzIHlvdXIgZnJpZW5kLi4uDQoNCj4gPiANCj4gPiBCdXQgdGhl -IHBlcmZvcm1hbmNlIGdhaW4gb2YgY29weSBvZmZsb2FkIGlzIHRvbyBiaWcgdG8ganVzdCBpZ25v -cmUsDQo+ID4gYW5kDQo+ID4gaW4gZmFjdCBpdCdzIHdoYXQgY29weV9maWxlX3JhbmdlIGRvZXMg -b24gZXZlcnkgZmlsZXN5c3RlbSBidXQNCj4gPiBidHJmcyBhbmQNCj4gPiBvY2ZzMiAoYW5kIG1h -eWJlIGNpZnM/KSwgc28gSSBkb24ndCB0aGluayB3ZSBjYW4ganVzdCBpZ25vcmUgaXQuDQo+ID4g -DQo+ID4gSWYgd2UgaGFkIHNlcGFyYXRlIGNvcHlfZmlsZV9yYW5nZSBhbmQgY2xvbmVfZmlsZV9y -YW5nZSwgSSAqdGhpbmsqDQo+ID4gaXQNCj4gPiBjb3VsZCBhbGwgYmUgbWFkZSBzZW5zaWJsZS7C -oMKgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPiANCj4gDQo+IEhvdyB3b3VsZCB0aGUgYXBw -bGljYXRpb24gKGNwKSBrbm93IHdoZW4gdG8gY2FsbCB0aGUgY2xvbmVfZmlsZV9yYW5nZQ0KPiBh -bmQgd2hlbiB0byBjYWxsIGNvcHlfZmlsZV9yYW5nZT8NCg0KY3AgY2FuIHByb2JhYmx5IGNhbGwg -Y29weV9maWxlX3JhbmdlKCksIGJ1dCBhbnkgYXBwbGljYXRpb24gdGhhdCBuZWVkcw0KYXRvbWlj -IHNlbWFudGljcyAoaS5lLiBhIGJpbmFyeSBvcGVyYXRpb24gc3VjY2Vzcy9mYWlsKSBtdXN0IGNh -bGwNCmNsb25lX2ZpbGVfcmFuZ2UoKS4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5G -UyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25kLm15a2xlYnVzdEBwcmltYXJ5 -ZGF0YS5jb20NCg== +On Wed, 2017-03-08 at 15:00 -0500, Olga Kornievskaia wrote: +> > On Mar 8, 2017, at 2:53 PM, J. Bruce Fields <bfields@fieldses.org> +> > wrote: +> > +> > On Wed, Mar 08, 2017 at 12:32:12PM -0500, Olga Kornievskaia wrote: +> > > +> > > > On Mar 8, 2017, at 12:25 PM, Christoph Hellwig <hch@infradead.o +> > > > rg> +> > > > wrote: +> > > > +> > > > On Wed, Mar 08, 2017 at 12:05:21PM -0500, J. Bruce Fields +> > > > wrote: +> > > > > Since copy isn't atomic that check is never going to be +> > > > > reliable. +> > > > +> > > > That's true for everything that COPY does. By that logic we +> > > > should +> > > > not implement it at all (a logic that I'd fully support) +> > > +> > > If you were to only keep CLONE then you’d lose a huge performance +> > > gain +> > > you get from server-to-server COPY. +> > +> > Yes. Also, I think copy-like copy implementations have reasonable +> > semantics that are basically the same as read: +> > +> > - copy can return successfully with less copied than requested. +> > - it's fine for the copied range to start and/or end past end +> > of +> > file, it'll just return a short read. +> > - A copy of more than 0 bytes returning 0 means you're at end +> > of +> > file. +> > +> > The particular problem here is that that doesn't fit how clone +> > works at +> > all. +> > +> > It feels like what happened is that copy_file_range() was made +> > mainly +> > for the clone case, with the idea that copy might be reluctantly +> > accepted as a second-class implementation. + +Historically? No... Christoph added clone as a valid implementation of +copy_file_range() almost a year after Zach and Anna defined the +semantics of vfs_copy_file_range(). git blame is your friend... + +> > +> > But the performance gain of copy offload is too big to just ignore, +> > and +> > in fact it's what copy_file_range does on every filesystem but +> > btrfs and +> > ocfs2 (and maybe cifs?), so I don't think we can just ignore it. +> > +> > If we had separate copy_file_range and clone_file_range, I *think* +> > it +> > could all be made sensible. Am I missing something? +> > +> +> How would the application (cp) know when to call the clone_file_range +> and when to call copy_file_range? + +cp can probably call copy_file_range(), but any application that needs +atomic semantics (i.e. a binary operation success/fail) must call +clone_file_range(). + +-- +Trond Myklebust +Linux NFS client maintainer, PrimaryData +trond.myklebust@primarydata.com diff --git a/a/content_digest b/N1/content_digest index 689d885..7e85e73 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,50 +19,75 @@ " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0" "\00:1\0" "b\0" - "T24gV2VkLCAyMDE3LTAzLTA4IGF0IDE1OjAwIC0wNTAwLCBPbGdhIEtvcm5pZXZza2FpYSB3cm90\n" - "ZToNCj4gPiBPbiBNYXIgOCwgMjAxNywgYXQgMjo1MyBQTSwgSi4gQnJ1Y2UgRmllbGRzIDxiZmll\n" - "bGRzQGZpZWxkc2VzLm9yZz4NCj4gPiB3cm90ZToNCj4gPiANCj4gPiBPbiBXZWQsIE1hciAwOCwg\n" - "MjAxNyBhdCAxMjozMjoxMlBNIC0wNTAwLCBPbGdhIEtvcm5pZXZza2FpYSB3cm90ZToNCj4gPiA+\n" - "IA0KPiA+ID4gPiBPbiBNYXIgOCwgMjAxNywgYXQgMTI6MjUgUE0sIENocmlzdG9waCBIZWxsd2ln\n" - "IDxoY2hAaW5mcmFkZWFkLm8NCj4gPiA+ID4gcmc+DQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiAN\n" - "Cj4gPiA+ID4gT24gV2VkLCBNYXIgMDgsIDIwMTcgYXQgMTI6MDU6MjFQTSAtMDUwMCwgSi4gQnJ1\n" - "Y2UgRmllbGRzDQo+ID4gPiA+IHdyb3RlOg0KPiA+ID4gPiA+IFNpbmNlIGNvcHkgaXNuJ3QgYXRv\n" - "bWljIHRoYXQgY2hlY2sgaXMgbmV2ZXIgZ29pbmcgdG8gYmUNCj4gPiA+ID4gPiByZWxpYWJsZS4N\n" - "Cj4gPiA+ID4gDQo+ID4gPiA+IFRoYXQncyB0cnVlIGZvciBldmVyeXRoaW5nIHRoYXQgQ09QWSBk\n" - "b2VzLsKgwqBCeSB0aGF0IGxvZ2ljIHdlDQo+ID4gPiA+IHNob3VsZA0KPiA+ID4gPiBub3QgaW1w\n" - "bGVtZW50IGl0IGF0IGFsbCAoYSBsb2dpYyB0aGF0IEknZCBmdWxseSBzdXBwb3J0KQ0KPiA+ID4g\n" - "DQo+ID4gPiBJZiB5b3Ugd2VyZSB0byBvbmx5IGtlZXAgQ0xPTkUgdGhlbiB5b3XigJlkIGxvc2Ug\n" - "YSBodWdlIHBlcmZvcm1hbmNlDQo+ID4gPiBnYWluDQo+ID4gPiB5b3UgZ2V0IGZyb20gc2VydmVy\n" - "LXRvLXNlcnZlciBDT1BZLsKgDQo+ID4gDQo+ID4gWWVzLsKgwqBBbHNvLCBJIHRoaW5rIGNvcHkt\n" - "bGlrZSBjb3B5IGltcGxlbWVudGF0aW9ucyBoYXZlIHJlYXNvbmFibGUNCj4gPiBzZW1hbnRpY3Mg\n" - "dGhhdCBhcmUgYmFzaWNhbGx5IHRoZSBzYW1lIGFzIHJlYWQ6DQo+ID4gDQo+ID4gCS0gY29weSBj\n" - "YW4gcmV0dXJuIHN1Y2Nlc3NmdWxseSB3aXRoIGxlc3MgY29waWVkIHRoYW4gcmVxdWVzdGVkLg0K\n" - "PiA+IAktIGl0J3MgZmluZSBmb3IgdGhlIGNvcGllZCByYW5nZSB0byBzdGFydCBhbmQvb3IgZW5k\n" - "IHBhc3QgZW5kDQo+ID4gb2YNCj4gPiAJwqDCoGZpbGUsIGl0J2xsIGp1c3QgcmV0dXJuIGEgc2hv\n" - "cnQgcmVhZC4NCj4gPiAJLSBBIGNvcHkgb2YgbW9yZSB0aGFuIDAgYnl0ZXMgcmV0dXJuaW5nIDAg\n" - "bWVhbnMgeW91J3JlIGF0IGVuZA0KPiA+IG9mDQo+ID4gCcKgwqBmaWxlLg0KPiA+IA0KPiA+IFRo\n" - "ZSBwYXJ0aWN1bGFyIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRoYXQgZG9lc24ndCBmaXQgaG93IGNs\n" - "b25lDQo+ID4gd29ya3MgYXQNCj4gPiBhbGwuDQo+ID4gDQo+ID4gSXQgZmVlbHMgbGlrZSB3aGF0\n" - "IGhhcHBlbmVkIGlzIHRoYXQgY29weV9maWxlX3JhbmdlKCkgd2FzIG1hZGUNCj4gPiBtYWlubHkN\n" - "Cj4gPiBmb3IgdGhlIGNsb25lIGNhc2UsIHdpdGggdGhlIGlkZWEgdGhhdCBjb3B5IG1pZ2h0IGJl\n" - "IHJlbHVjdGFudGx5DQo+ID4gYWNjZXB0ZWQgYXMgYSBzZWNvbmQtY2xhc3MgaW1wbGVtZW50YXRp\n" - "b24uDQoNCkhpc3RvcmljYWxseT8gTm8uLi4gQ2hyaXN0b3BoIGFkZGVkIGNsb25lIGFzIGEgdmFs\n" - "aWQgaW1wbGVtZW50YXRpb24gb2YNCmNvcHlfZmlsZV9yYW5nZSgpIGFsbW9zdCBhIHllYXIgYWZ0\n" - "ZXIgWmFjaCBhbmQgQW5uYSBkZWZpbmVkIHRoZQ0Kc2VtYW50aWNzIG9mIHZmc19jb3B5X2ZpbGVf\n" - "cmFuZ2UoKS4gZ2l0IGJsYW1lIGlzIHlvdXIgZnJpZW5kLi4uDQoNCj4gPiANCj4gPiBCdXQgdGhl\n" - "IHBlcmZvcm1hbmNlIGdhaW4gb2YgY29weSBvZmZsb2FkIGlzIHRvbyBiaWcgdG8ganVzdCBpZ25v\n" - "cmUsDQo+ID4gYW5kDQo+ID4gaW4gZmFjdCBpdCdzIHdoYXQgY29weV9maWxlX3JhbmdlIGRvZXMg\n" - "b24gZXZlcnkgZmlsZXN5c3RlbSBidXQNCj4gPiBidHJmcyBhbmQNCj4gPiBvY2ZzMiAoYW5kIG1h\n" - "eWJlIGNpZnM/KSwgc28gSSBkb24ndCB0aGluayB3ZSBjYW4ganVzdCBpZ25vcmUgaXQuDQo+ID4g\n" - "DQo+ID4gSWYgd2UgaGFkIHNlcGFyYXRlIGNvcHlfZmlsZV9yYW5nZSBhbmQgY2xvbmVfZmlsZV9y\n" - "YW5nZSwgSSAqdGhpbmsqDQo+ID4gaXQNCj4gPiBjb3VsZCBhbGwgYmUgbWFkZSBzZW5zaWJsZS7C\n" - "oMKgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gPiANCj4gDQo+IEhvdyB3b3VsZCB0aGUgYXBw\n" - "bGljYXRpb24gKGNwKSBrbm93IHdoZW4gdG8gY2FsbCB0aGUgY2xvbmVfZmlsZV9yYW5nZQ0KPiBh\n" - "bmQgd2hlbiB0byBjYWxsIGNvcHlfZmlsZV9yYW5nZT8NCg0KY3AgY2FuIHByb2JhYmx5IGNhbGwg\n" - "Y29weV9maWxlX3JhbmdlKCksIGJ1dCBhbnkgYXBwbGljYXRpb24gdGhhdCBuZWVkcw0KYXRvbWlj\n" - "IHNlbWFudGljcyAoaS5lLiBhIGJpbmFyeSBvcGVyYXRpb24gc3VjY2Vzcy9mYWlsKSBtdXN0IGNh\n" - "bGwNCmNsb25lX2ZpbGVfcmFuZ2UoKS4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5G\n" - "UyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25kLm15a2xlYnVzdEBwcmltYXJ5\n" - ZGF0YS5jb20NCg== + "On Wed, 2017-03-08 at 15:00 -0500, Olga Kornievskaia wrote:\n" + "> > On Mar 8, 2017, at 2:53 PM, J. Bruce Fields <bfields@fieldses.org>\n" + "> > wrote:\n" + "> > \n" + "> > On Wed, Mar 08, 2017 at 12:32:12PM -0500, Olga Kornievskaia wrote:\n" + "> > > \n" + "> > > > On Mar 8, 2017, at 12:25 PM, Christoph Hellwig <hch@infradead.o\n" + "> > > > rg>\n" + "> > > > wrote:\n" + "> > > > \n" + "> > > > On Wed, Mar 08, 2017 at 12:05:21PM -0500, J. Bruce Fields\n" + "> > > > wrote:\n" + "> > > > > Since copy isn't atomic that check is never going to be\n" + "> > > > > reliable.\n" + "> > > > \n" + "> > > > That's true for everything that COPY does.\302\240\302\240By that logic we\n" + "> > > > should\n" + "> > > > not implement it at all (a logic that I'd fully support)\n" + "> > > \n" + "> > > If you were to only keep CLONE then you\342\200\231d lose a huge performance\n" + "> > > gain\n" + "> > > you get from server-to-server COPY.\302\240\n" + "> > \n" + "> > Yes.\302\240\302\240Also, I think copy-like copy implementations have reasonable\n" + "> > semantics that are basically the same as read:\n" + "> > \n" + "> > \t- copy can return successfully with less copied than requested.\n" + "> > \t- it's fine for the copied range to start and/or end past end\n" + "> > of\n" + "> > \t\302\240\302\240file, it'll just return a short read.\n" + "> > \t- A copy of more than 0 bytes returning 0 means you're at end\n" + "> > of\n" + "> > \t\302\240\302\240file.\n" + "> > \n" + "> > The particular problem here is that that doesn't fit how clone\n" + "> > works at\n" + "> > all.\n" + "> > \n" + "> > It feels like what happened is that copy_file_range() was made\n" + "> > mainly\n" + "> > for the clone case, with the idea that copy might be reluctantly\n" + "> > accepted as a second-class implementation.\n" + "\n" + "Historically? No... Christoph added clone as a valid implementation of\n" + "copy_file_range() almost a year after Zach and Anna defined the\n" + "semantics of vfs_copy_file_range(). git blame is your friend...\n" + "\n" + "> > \n" + "> > But the performance gain of copy offload is too big to just ignore,\n" + "> > and\n" + "> > in fact it's what copy_file_range does on every filesystem but\n" + "> > btrfs and\n" + "> > ocfs2 (and maybe cifs?), so I don't think we can just ignore it.\n" + "> > \n" + "> > If we had separate copy_file_range and clone_file_range, I *think*\n" + "> > it\n" + "> > could all be made sensible.\302\240\302\240Am I missing something?\n" + "> > \n" + "> \n" + "> How would the application (cp) know when to call the clone_file_range\n" + "> and when to call copy_file_range?\n" + "\n" + "cp can probably call copy_file_range(), but any application that needs\n" + "atomic semantics (i.e. a binary operation success/fail) must call\n" + "clone_file_range().\n" + "\n" + "-- \n" + "Trond Myklebust\n" + "Linux NFS client maintainer, PrimaryData\n" + trond.myklebust@primarydata.com -17bd16ae73ab9976a0b06cbee3e9892f73501ad9e5830c78e8244cb1fd5f51be +3f123b54ff836ed07e761633ca0d3c888d6d177e96e1568d742046216919a28e
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.