diff for duplicates of <1462484695.29294.7.camel@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index b18755c..3a45571 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,30 +1,40 @@
-T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA4OjIyIC0wNzAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90
-ZToNCj4gT24gVGh1LCBNYXkgMDUsIDIwMTYgYXQgMDg6MTU6MzJBTSAtMDcwMCwgRGFuIFdpbGxp
-YW1zIHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBZ3JlZWQgLSBtYWtpZyBPX0RJUkVDVCBs
-ZXNzIGRpcmVjdCB0aGFuIG5vdCBoYXZpbmcgaXQgaXMgcGxhaW4NCj4gPiA+IHN0dXBpZCwNCj4g
-PiA+IGFuZCBJIHNvbWVob3cgbWlzc2VkIHRoaXMgaW5pdGlhbGx5Lg0KPiA+IE9mIGNvdXJzZSBJ
-IGRpc2FncmVlIGJlY2F1c2UgbGlrZSBEYXZlIGFyZ3VlcyBpbiB0aGUgbXN5bmMgY2FzZSB3ZQ0K
-PiA+IHNob3VsZCBkbyB0aGUgY29ycmVjdCB0aGluZyBmaXJzdCBhbmQgbWFrZSBpdCBmYXN0IGxh
-dGVyLCBidXQgYWxzbw0KPiA+IGxpa2UgRGF2ZSB0aGlzIGFyZ3VpbmcgaW4gY2lyY2xlcyBpcyBn
-ZXR0aW5nIHRpcmVzb21lLg0KPiBXZSBzaG91bGQgZG8gdGhlIHJpZ2h0IHRoaW5nIGZpcnN0LCBh
-bmQgbWFrZSBpdCBmYXN0IGxhdGVyLsKgwqBCdXQgdGhpcw0KPiBwcm9wb3NhbCBpcyBub3QgZ2V0
-dGluZyBpdCByaWdodCAtIGl0IHN0aWxsIGRvZXMgbm90IGhhbmRsZSBlcnJvcnMNCj4gZm9yIHRo
-ZSBmYXN0IHBhdGgsIGJ1dCBtYWdpY2FsbHkgbWFrZXMgaXQgd29yayBmb3IgZGlyZWN0IEkvTyBi
-eQ0KPiBpbiBnZW5lcmFsIHVzaW5nIGEgbGVzcyBvcHRpb25hbCBwYXRoIGZvciBPX0RJUkVDVC7C
-oMKgSXQncyBnZXR0aW5nIHRoZQ0KPiB3b3JzdCBvZiBhbGwgY2hvaWNlcy4NCj4gDQo+IEFzIGZh
-ciBhcyBJIGNhbiB0ZWxsIHRoZSBvbmx5IHNlbnNpYmxlIG9wdGlvbiBpcyB0bzoNCj4gDQo+IMKg
-LSBhbHdheXMgdHJ5IGRheC1saWtlIEkvTyBmaXJzdA0KPiDCoC0gaGF2ZSBhIGN1c3RvbSBnZXRf
-dXNlcl9wYWdlcyArIHJ3X2J5dGVzIGZhbGxiYWNrIGhhbmRsZXMgYmFkIGJsb2Nrcw0KPiDCoMKg
-wqB3aGVuIGhpdHRpbmcgRUlPDQoNCkknbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJzdGFu
-ZCBob3cgdGhpcyB3aWxsIHdvcms/IENhbiB5b3UgZXhwbGFpbg0KYSBiaXQ/IFdvdWxkIHdlIGhh
-dmUgdG8gZXhwb3J0IHJ3X2J5dGVzIHVwIHRvIGxheWVycyBhYm92ZSB0aGUgcG1lbQ0KZHJpdmVy
-PyBXaGVyZSBkb2VzIGdldF91c2VyX3BhZ2VzIGNvbWUgaW4/DQoNCj4gDQo+IEFuZCB0aGVuIHdl
-IG5lZWQgdG8gc29ydCBvdXQgdGhlIGNvbmN1cnJlbnQgd3JpdGUgc3luY2hyb25pemF0aW9uLg0K
-PiBBZ2FpbiB0aGVyZSBJIHRoaW5rIHdlIGFic29sdXRlbHkgaGF2ZSB0byBvYmV5IFBvc2l4IGZv
-ciB0aGUgIU9fRElSRUNUDQo+IGNhc2UgYW5kIGNhbiBhdm9pZCBpdCBmb3IgT19ESVJFQ1QsIHNp
-bWlsYXIgdG8gdGhlIGV4aXN0aW5nIG5vbi1EQVgNCj4gc2VtYW50aWNzLsKgwqBJZiB3ZSB3YW50
-IGFueSBzcGVjaWFsIGFkZGl0aW9uYWwgc2VtYW50aWNzIHdlIF93aWxsXyBuZWVkDQo+IGEgc3Bl
-Y2lhbCBPX0RBWCBmbGFnLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
-X19fX19fX19fXw0KPiBMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0DQo+IExpbnV4LW52ZGltbUBs
-aXN0cy4wMS5vcmcNCj4gaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51
-eC1udmRpbW0=
+On Thu, 2016-05-05 at 08:22 -0700, Christoph Hellwig wrote:
+> On Thu, May 05, 2016 at 08:15:32AM -0700, Dan Williams wrote:
+> > 
+> > > 
+> > > Agreed - makig O_DIRECT less direct than not having it is plain
+> > > stupid,
+> > > and I somehow missed this initially.
+> > Of course I disagree because like Dave argues in the msync case we
+> > should do the correct thing first and make it fast later, but also
+> > like Dave this arguing in circles is getting tiresome.
+> We should do the right thing first, and make it fast later.  But this
+> proposal is not getting it right - it still does not handle errors
+> for the fast path, but magically makes it work for direct I/O by
+> in general using a less optional path for O_DIRECT.  It's getting the
+> worst of all choices.
+> 
+> As far as I can tell the only sensible option is to:
+> 
+>  - always try dax-like I/O first
+>  - have a custom get_user_pages + rw_bytes fallback handles bad blocks
+>    when hitting EIO
+
+I'm not sure I completely understand how this will work? Can you explain
+a bit? Would we have to export rw_bytes up to layers above the pmem
+driver? Where does get_user_pages come in?
+
+> 
+> And then we need to sort out the concurrent write synchronization.
+> Again there I think we absolutely have to obey Posix for the !O_DIRECT
+> case and can avoid it for O_DIRECT, similar to the existing non-DAX
+> semantics.  If we want any special additional semantics we _will_ need
+> a special O_DAX flag.
+> _______________________________________________
+> Linux-nvdimm mailing list
+> Linux-nvdimm@lists.01.org
+> https://lists.01.org/mailman/listinfo/linux-nvdimm
+_______________________________________________
+xfs mailing list
+xfs@oss.sgi.com
+http://oss.sgi.com/mailman/listinfo/xfs
diff --git a/a/content_digest b/N1/content_digest
index 475c59a..969c7a7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -10,50 +10,59 @@
  "To\0Williams"
   Dan J <dan.j.williams@intel.com>
  " hch@infradead.org <hch@infradead.org>\0"
- "Cc\0linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>"
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
-  xfs@oss.sgi.com <xfs@oss.sgi.com>
+ "Cc\0axboe@fb.com <axboe@fb.com>"
+  jack@suse.cz <jack@suse.cz>
+  matthew@wil.cx <matthew@wil.cx>
   linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
+  linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
+  xfs@oss.sgi.com <xfs@oss.sgi.com>
+  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
   linux-mm@kvack.org <linux-mm@kvack.org>
   viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk>
-  axboe@fb.com <axboe@fb.com>
-  akpm@linux-foundation.org <akpm@linux-foundation.org>
   linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
-  linux-ext4@vger.kernel.org <linux-ext4@vger.kernel.org>
-  david@fromorbit.com <david@fromorbit.com>
-  jack@suse.cz <jack@suse.cz>
- " matthew@wil.cx <matthew@wil.cx>\0"
+  akpm@linux-foundation.org <akpm@linux-foundation.org>
+ " linux-ext4@vger.kernel.org <linux-ext4@vger.kernel.org>\0"
  "\00:1\0"
  "b\0"
- "T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA4OjIyIC0wNzAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90\n"
- "ZToNCj4gT24gVGh1LCBNYXkgMDUsIDIwMTYgYXQgMDg6MTU6MzJBTSAtMDcwMCwgRGFuIFdpbGxp\n"
- "YW1zIHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBZ3JlZWQgLSBtYWtpZyBPX0RJUkVDVCBs\n"
- "ZXNzIGRpcmVjdCB0aGFuIG5vdCBoYXZpbmcgaXQgaXMgcGxhaW4NCj4gPiA+IHN0dXBpZCwNCj4g\n"
- "PiA+IGFuZCBJIHNvbWVob3cgbWlzc2VkIHRoaXMgaW5pdGlhbGx5Lg0KPiA+IE9mIGNvdXJzZSBJ\n"
- "IGRpc2FncmVlIGJlY2F1c2UgbGlrZSBEYXZlIGFyZ3VlcyBpbiB0aGUgbXN5bmMgY2FzZSB3ZQ0K\n"
- "PiA+IHNob3VsZCBkbyB0aGUgY29ycmVjdCB0aGluZyBmaXJzdCBhbmQgbWFrZSBpdCBmYXN0IGxh\n"
- "dGVyLCBidXQgYWxzbw0KPiA+IGxpa2UgRGF2ZSB0aGlzIGFyZ3VpbmcgaW4gY2lyY2xlcyBpcyBn\n"
- "ZXR0aW5nIHRpcmVzb21lLg0KPiBXZSBzaG91bGQgZG8gdGhlIHJpZ2h0IHRoaW5nIGZpcnN0LCBh\n"
- "bmQgbWFrZSBpdCBmYXN0IGxhdGVyLsKgwqBCdXQgdGhpcw0KPiBwcm9wb3NhbCBpcyBub3QgZ2V0\n"
- "dGluZyBpdCByaWdodCAtIGl0IHN0aWxsIGRvZXMgbm90IGhhbmRsZSBlcnJvcnMNCj4gZm9yIHRo\n"
- "ZSBmYXN0IHBhdGgsIGJ1dCBtYWdpY2FsbHkgbWFrZXMgaXQgd29yayBmb3IgZGlyZWN0IEkvTyBi\n"
- "eQ0KPiBpbiBnZW5lcmFsIHVzaW5nIGEgbGVzcyBvcHRpb25hbCBwYXRoIGZvciBPX0RJUkVDVC7C\n"
- "oMKgSXQncyBnZXR0aW5nIHRoZQ0KPiB3b3JzdCBvZiBhbGwgY2hvaWNlcy4NCj4gDQo+IEFzIGZh\n"
- "ciBhcyBJIGNhbiB0ZWxsIHRoZSBvbmx5IHNlbnNpYmxlIG9wdGlvbiBpcyB0bzoNCj4gDQo+IMKg\n"
- "LSBhbHdheXMgdHJ5IGRheC1saWtlIEkvTyBmaXJzdA0KPiDCoC0gaGF2ZSBhIGN1c3RvbSBnZXRf\n"
- "dXNlcl9wYWdlcyArIHJ3X2J5dGVzIGZhbGxiYWNrIGhhbmRsZXMgYmFkIGJsb2Nrcw0KPiDCoMKg\n"
- "wqB3aGVuIGhpdHRpbmcgRUlPDQoNCkknbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJzdGFu\n"
- "ZCBob3cgdGhpcyB3aWxsIHdvcms/IENhbiB5b3UgZXhwbGFpbg0KYSBiaXQ/IFdvdWxkIHdlIGhh\n"
- "dmUgdG8gZXhwb3J0IHJ3X2J5dGVzIHVwIHRvIGxheWVycyBhYm92ZSB0aGUgcG1lbQ0KZHJpdmVy\n"
- "PyBXaGVyZSBkb2VzIGdldF91c2VyX3BhZ2VzIGNvbWUgaW4/DQoNCj4gDQo+IEFuZCB0aGVuIHdl\n"
- "IG5lZWQgdG8gc29ydCBvdXQgdGhlIGNvbmN1cnJlbnQgd3JpdGUgc3luY2hyb25pemF0aW9uLg0K\n"
- "PiBBZ2FpbiB0aGVyZSBJIHRoaW5rIHdlIGFic29sdXRlbHkgaGF2ZSB0byBvYmV5IFBvc2l4IGZv\n"
- "ciB0aGUgIU9fRElSRUNUDQo+IGNhc2UgYW5kIGNhbiBhdm9pZCBpdCBmb3IgT19ESVJFQ1QsIHNp\n"
- "bWlsYXIgdG8gdGhlIGV4aXN0aW5nIG5vbi1EQVgNCj4gc2VtYW50aWNzLsKgwqBJZiB3ZSB3YW50\n"
- "IGFueSBzcGVjaWFsIGFkZGl0aW9uYWwgc2VtYW50aWNzIHdlIF93aWxsXyBuZWVkDQo+IGEgc3Bl\n"
- "Y2lhbCBPX0RBWCBmbGFnLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n"
- "X19fX19fX19fXw0KPiBMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0DQo+IExpbnV4LW52ZGltbUBs\n"
- "aXN0cy4wMS5vcmcNCj4gaHR0cHM6Ly9saXN0cy4wMS5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51\n"
- eC1udmRpbW0=
+ "On Thu, 2016-05-05 at 08:22 -0700, Christoph Hellwig wrote:\n"
+ "> On Thu, May 05, 2016 at 08:15:32AM -0700, Dan Williams wrote:\n"
+ "> > \n"
+ "> > > \n"
+ "> > > Agreed - makig O_DIRECT less direct than not having it is plain\n"
+ "> > > stupid,\n"
+ "> > > and I somehow missed this initially.\n"
+ "> > Of course I disagree because like Dave argues in the msync case we\n"
+ "> > should do the correct thing first and make it fast later, but also\n"
+ "> > like Dave this arguing in circles is getting tiresome.\n"
+ "> We should do the right thing first, and make it fast later.\302\240\302\240But this\n"
+ "> proposal is not getting it right - it still does not handle errors\n"
+ "> for the fast path, but magically makes it work for direct I/O by\n"
+ "> in general using a less optional path for O_DIRECT.\302\240\302\240It's getting the\n"
+ "> worst of all choices.\n"
+ "> \n"
+ "> As far as I can tell the only sensible option is to:\n"
+ "> \n"
+ "> \302\240- always try dax-like I/O first\n"
+ "> \302\240- have a custom get_user_pages + rw_bytes fallback handles bad blocks\n"
+ "> \302\240\302\240\302\240when hitting EIO\n"
+ "\n"
+ "I'm not sure I completely understand how this will work? Can you explain\n"
+ "a bit? Would we have to export rw_bytes up to layers above the pmem\n"
+ "driver? Where does get_user_pages come in?\n"
+ "\n"
+ "> \n"
+ "> And then we need to sort out the concurrent write synchronization.\n"
+ "> Again there I think we absolutely have to obey Posix for the !O_DIRECT\n"
+ "> case and can avoid it for O_DIRECT, similar to the existing non-DAX\n"
+ "> semantics.\302\240\302\240If we want any special additional semantics we _will_ need\n"
+ "> a special O_DAX flag.\n"
+ "> _______________________________________________\n"
+ "> Linux-nvdimm mailing list\n"
+ "> Linux-nvdimm@lists.01.org\n"
+ "> https://lists.01.org/mailman/listinfo/linux-nvdimm\n"
+ "_______________________________________________\n"
+ "xfs mailing list\n"
+ "xfs@oss.sgi.com\n"
+ http://oss.sgi.com/mailman/listinfo/xfs
 
-32092709c38194cc19a2c1d44d33d30202ccd28ad53b93a5269b8789ea984828
+a8b2de9c1c4a7e30bcd07e757630402892b93a7b44aa3dbe9e93a695ddb255b8
