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

diff --git a/a/1.txt b/N1/1.txt
index 8490497..468023b 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,33 +1,50 @@
-T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA3OjI0IC0wNzAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90
-ZToNCj4gT24gTW9uLCBNYXkgMDIsIDIwMTYgYXQgMDY6NDE6NTFQTSArMDMwMCwgQm9heiBIYXJy
-b3NoIHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBbGwgSU8gaW4gYSBkYXggZmlsZXN5c3Rl
-bSB1c2VkIHRvIGdvIHRocm91Z2ggZGF4X2RvX2lvLCB3aGljaA0KPiA+ID4gY2Fubm90DQo+ID4g
-PiBoYW5kbGUgbWVkaWEgZXJyb3JzLCBhbmQgdGh1cyBjYW5ub3QgcHJvdmlkZSBhIHJlY292ZXJ5
-IHBhdGggdGhhdA0KPiA+ID4gY2FuDQo+ID4gPiBzZW5kIGEgd3JpdGUgdGhyb3VnaCB0aGUgZHJp
-dmVyIHRvIGNsZWFyIGVycm9ycy4NCj4gPiA+IA0KPiA+ID4gQWRkIGEgbmV3IGlvY2IgZmxhZyBm
-b3IgREFYLCBhbmQgc2V0IGl0IG9ubHkgZm9yIERBWCBtb3VudHMuIEluDQo+ID4gPiB0aGUgSU8N
-Cj4gPiA+IHBhdGggZm9yIERBWCBmaWxlc3lzdGVtcywgdXNlIHRoZSBzYW1lIGRpcmVjdF9JTyBw
-YXRoIGZvciBib3RoIERBWA0KPiA+ID4gYW5kDQo+ID4gPiBkaXJlY3RfaW8gaW9jYnMsIGJ1dCB1
-c2UgdGhlIGZsYWdzIHRvIGlkZW50aWZ5IHdoZW4gd2UgYXJlIGluDQo+ID4gPiBPX0RJUkVDVA0K
-PiA+ID4gbW9kZSB2cyBub24gT19ESVJFQ1Qgd2l0aCBEQVgsIGFuZCBmb3IgT19ESVJFQ1QsIHVz
-ZSB0aGUNCj4gPiA+IGNvbnZlbnRpb25hbA0KPiA+ID4gZGlyZWN0X0lPIHBhdGggaW5zdGVhZCBv
-ZiBEQVguDQo+ID4gPiANCj4gPiBSZWFsbHk/IFdoYXQgYXJlIHlvdXIgdGhpbmtpbmcgaGVyZT8N
-Cj4gPiANCj4gPiBXaGF0IGFib3V0IGFsbCB0aGUgY3VycmVudCB1c2VycyBvZiBPX0RJUkVDVCwg
-eW91IGhhdmUganVzdCBtYWRlDQo+ID4gdGhlbQ0KPiA+IDQgdGltZXMgc2xvd2VyIGFuZCAibGVz
-cyBjb25jdXJyZW50KiIgdGhlbiAiYnVmZnJlZCBpbyIgdXNlcnMuIFNpbmNlDQo+ID4gZGlyZWN0
-X0lPIHBhdGggd2lsbCBxdWV1ZSBhbiBJTyByZXF1ZXN0IGFuZCBhbGwuDQo+ID4gKEFuZCBpZiBp
-dCBpcyBub3Qgc28gc2xvdyB0aGVuIHdoeSBkbyB3ZSBuZWVkIGRheF9kb19pbyBhdCBhbGw/DQo+
-ID4gW1JoZXRvcmljYWxdKQ0KPiA+IA0KPiA+IEkgaGF0ZSBpdCB0aGF0IHlvdSBvdmVybG9hZCB0
-aGUgc2VtYW50aWNzIG9mIGEga25vd24gYW5kIGV4cGVjdGVkDQo+ID4gT19ESVJFQ1QgZmxhZywg
-Zm9yIHNwZWNpYWwgcG1lbSBxdWlya3MuIFRoaXMgaXMgYW4gaW5jb21wYXRpYmxlDQo+ID4gYW5k
-IHVucmVsYXRlZCBvdmVybG9hZCBvZiB0aGUgc2VtYW50aWNzIG9mIE9fRElSRUNULg0KPiBBZ3Jl
-ZWQgLSBtYWtpZyBPX0RJUkVDVCBsZXNzIGRpcmVjdCB0aGFuIG5vdCBoYXZpbmcgaXQgaXMgcGxh
-aW4NCj4gc3R1cGlkLA0KPiBhbmQgSSBzb21laG93IG1pc3NlZCB0aGlzIGluaXRpYWxseS4NCg0K
-SG93IGlzIGl0IGFueSAnbGVzcyBkaXJlY3QnPyBBbGwgaXQgZG9lcyBub3cgaXMgZm9sbG93IHRo
-ZSBibG9ja2Rldg0KT19ESVJFQ1QgcGF0aC4gVGhlcmUgc3RpbGwgaXNuJ3QgYW55IHBhZ2UgY2Fj
-aGUgaW52b2x2ZWQuLg0KDQo+IA0KPiBUaGlzIHdob2xlIERBWCBzdG9yeSB0dXJucyBpbnRvIGEg
-bWFqb3IgbmlnaHRtYXJlLCBhbmQgSSBmZWFyIGFsbCBvdXINCj4gaG9kZ2UgcG9kZ2UgdHdlYWtz
-IHRvIHRoZSBzZW1hbnRpY3MgYXJlbid0IGhlbHBpbmcgaXQuDQo+IA0KPiBJdCBzZWVtcyBsaWtl
-IHdlIHNpbXBseSBuZWVkIGFuIGV4cGxpY2l0IE9fREFYIGZvciB0aGUgcmVhZC93cml0ZQ0KPiBi
-eXBhc3MgaWYgY2FuJ3Qgc29ydCBvdXQgdGhlIHNlbWFudGljcyAoZXJyb3IsIHdyaXRlciBzeW5j
-aHJvbml6YXRpb24pDQo+IGp1c3QgYXMgd2UgbmVlZCBhIHNwZWNpYWwgZmxhZyBmb3IgTU1BUC4u
+On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:
+> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
+> > 
+> > > 
+> > > All IO in a dax filesystem used to go through dax_do_io, which
+> > > cannot
+> > > handle media errors, and thus cannot provide a recovery path that
+> > > can
+> > > send a write through the driver to clear errors.
+> > > 
+> > > Add a new iocb flag for DAX, and set it only for DAX mounts. In
+> > > the IO
+> > > path for DAX filesystems, use the same direct_IO path for both DAX
+> > > and
+> > > direct_io iocbs, but use the flags to identify when we are in
+> > > O_DIRECT
+> > > mode vs non O_DIRECT with DAX, and for O_DIRECT, use the
+> > > conventional
+> > > direct_IO path instead of DAX.
+> > > 
+> > Really? What are your thinking here?
+> > 
+> > What about all the current users of O_DIRECT, you have just made
+> > them
+> > 4 times slower and "less concurrent*" then "buffred io" users. Since
+> > direct_IO path will queue an IO request and all.
+> > (And if it is not so slow then why do we need dax_do_io at all?
+> > [Rhetorical])
+> > 
+> > I hate it that you overload the semantics of a known and expected
+> > O_DIRECT flag, for special pmem quirks. This is an incompatible
+> > and unrelated overload of the semantics of O_DIRECT.
+> Agreed - makig O_DIRECT less direct than not having it is plain
+> stupid,
+> and I somehow missed this initially.
+
+How is it any 'less direct'? All it does now is follow the blockdev
+O_DIRECT path. There still isn't any page cache involved..
+
+> 
+> This whole DAX story turns into a major nightmare, and I fear all our
+> hodge podge tweaks to the semantics aren't helping it.
+> 
+> It seems like we simply need an explicit O_DAX for the read/write
+> bypass if can't sort out the semantics (error, writer synchronization)
+> just as we need a special flag for MMAP..
+_______________________________________________
+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 91008f9..8a78ba2 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -7,53 +7,69 @@
  "Date\0Thu, 5 May 2016 21:39:14 +0000\0"
  "To\0hch@infradead.org <hch@infradead.org>"
  " boaz@plexistor.com <boaz@plexistor.com>\0"
- "Cc\0linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>"
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
+ "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>
-  akpm@linux-foundation.org <akpm@linux-foundation.org>
-  axboe@fb.com <axboe@fb.com>
   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"
- "T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA3OjI0IC0wNzAwLCBDaHJpc3RvcGggSGVsbHdpZyB3cm90\n"
- "ZToNCj4gT24gTW9uLCBNYXkgMDIsIDIwMTYgYXQgMDY6NDE6NTFQTSArMDMwMCwgQm9heiBIYXJy\n"
- "b3NoIHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBBbGwgSU8gaW4gYSBkYXggZmlsZXN5c3Rl\n"
- "bSB1c2VkIHRvIGdvIHRocm91Z2ggZGF4X2RvX2lvLCB3aGljaA0KPiA+ID4gY2Fubm90DQo+ID4g\n"
- "PiBoYW5kbGUgbWVkaWEgZXJyb3JzLCBhbmQgdGh1cyBjYW5ub3QgcHJvdmlkZSBhIHJlY292ZXJ5\n"
- "IHBhdGggdGhhdA0KPiA+ID4gY2FuDQo+ID4gPiBzZW5kIGEgd3JpdGUgdGhyb3VnaCB0aGUgZHJp\n"
- "dmVyIHRvIGNsZWFyIGVycm9ycy4NCj4gPiA+IA0KPiA+ID4gQWRkIGEgbmV3IGlvY2IgZmxhZyBm\n"
- "b3IgREFYLCBhbmQgc2V0IGl0IG9ubHkgZm9yIERBWCBtb3VudHMuIEluDQo+ID4gPiB0aGUgSU8N\n"
- "Cj4gPiA+IHBhdGggZm9yIERBWCBmaWxlc3lzdGVtcywgdXNlIHRoZSBzYW1lIGRpcmVjdF9JTyBw\n"
- "YXRoIGZvciBib3RoIERBWA0KPiA+ID4gYW5kDQo+ID4gPiBkaXJlY3RfaW8gaW9jYnMsIGJ1dCB1\n"
- "c2UgdGhlIGZsYWdzIHRvIGlkZW50aWZ5IHdoZW4gd2UgYXJlIGluDQo+ID4gPiBPX0RJUkVDVA0K\n"
- "PiA+ID4gbW9kZSB2cyBub24gT19ESVJFQ1Qgd2l0aCBEQVgsIGFuZCBmb3IgT19ESVJFQ1QsIHVz\n"
- "ZSB0aGUNCj4gPiA+IGNvbnZlbnRpb25hbA0KPiA+ID4gZGlyZWN0X0lPIHBhdGggaW5zdGVhZCBv\n"
- "ZiBEQVguDQo+ID4gPiANCj4gPiBSZWFsbHk/IFdoYXQgYXJlIHlvdXIgdGhpbmtpbmcgaGVyZT8N\n"
- "Cj4gPiANCj4gPiBXaGF0IGFib3V0IGFsbCB0aGUgY3VycmVudCB1c2VycyBvZiBPX0RJUkVDVCwg\n"
- "eW91IGhhdmUganVzdCBtYWRlDQo+ID4gdGhlbQ0KPiA+IDQgdGltZXMgc2xvd2VyIGFuZCAibGVz\n"
- "cyBjb25jdXJyZW50KiIgdGhlbiAiYnVmZnJlZCBpbyIgdXNlcnMuIFNpbmNlDQo+ID4gZGlyZWN0\n"
- "X0lPIHBhdGggd2lsbCBxdWV1ZSBhbiBJTyByZXF1ZXN0IGFuZCBhbGwuDQo+ID4gKEFuZCBpZiBp\n"
- "dCBpcyBub3Qgc28gc2xvdyB0aGVuIHdoeSBkbyB3ZSBuZWVkIGRheF9kb19pbyBhdCBhbGw/DQo+\n"
- "ID4gW1JoZXRvcmljYWxdKQ0KPiA+IA0KPiA+IEkgaGF0ZSBpdCB0aGF0IHlvdSBvdmVybG9hZCB0\n"
- "aGUgc2VtYW50aWNzIG9mIGEga25vd24gYW5kIGV4cGVjdGVkDQo+ID4gT19ESVJFQ1QgZmxhZywg\n"
- "Zm9yIHNwZWNpYWwgcG1lbSBxdWlya3MuIFRoaXMgaXMgYW4gaW5jb21wYXRpYmxlDQo+ID4gYW5k\n"
- "IHVucmVsYXRlZCBvdmVybG9hZCBvZiB0aGUgc2VtYW50aWNzIG9mIE9fRElSRUNULg0KPiBBZ3Jl\n"
- "ZWQgLSBtYWtpZyBPX0RJUkVDVCBsZXNzIGRpcmVjdCB0aGFuIG5vdCBoYXZpbmcgaXQgaXMgcGxh\n"
- "aW4NCj4gc3R1cGlkLA0KPiBhbmQgSSBzb21laG93IG1pc3NlZCB0aGlzIGluaXRpYWxseS4NCg0K\n"
- "SG93IGlzIGl0IGFueSAnbGVzcyBkaXJlY3QnPyBBbGwgaXQgZG9lcyBub3cgaXMgZm9sbG93IHRo\n"
- "ZSBibG9ja2Rldg0KT19ESVJFQ1QgcGF0aC4gVGhlcmUgc3RpbGwgaXNuJ3QgYW55IHBhZ2UgY2Fj\n"
- "aGUgaW52b2x2ZWQuLg0KDQo+IA0KPiBUaGlzIHdob2xlIERBWCBzdG9yeSB0dXJucyBpbnRvIGEg\n"
- "bWFqb3IgbmlnaHRtYXJlLCBhbmQgSSBmZWFyIGFsbCBvdXINCj4gaG9kZ2UgcG9kZ2UgdHdlYWtz\n"
- "IHRvIHRoZSBzZW1hbnRpY3MgYXJlbid0IGhlbHBpbmcgaXQuDQo+IA0KPiBJdCBzZWVtcyBsaWtl\n"
- "IHdlIHNpbXBseSBuZWVkIGFuIGV4cGxpY2l0IE9fREFYIGZvciB0aGUgcmVhZC93cml0ZQ0KPiBi\n"
- "eXBhc3MgaWYgY2FuJ3Qgc29ydCBvdXQgdGhlIHNlbWFudGljcyAoZXJyb3IsIHdyaXRlciBzeW5j\n"
- aHJvbml6YXRpb24pDQo+IGp1c3QgYXMgd2UgbmVlZCBhIHNwZWNpYWwgZmxhZyBmb3IgTU1BUC4u
+ "On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:\n"
+ "> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:\n"
+ "> > \n"
+ "> > > \n"
+ "> > > All IO in a dax filesystem used to go through dax_do_io, which\n"
+ "> > > cannot\n"
+ "> > > handle media errors, and thus cannot provide a recovery path that\n"
+ "> > > can\n"
+ "> > > send a write through the driver to clear errors.\n"
+ "> > > \n"
+ "> > > Add a new iocb flag for DAX, and set it only for DAX mounts. In\n"
+ "> > > the IO\n"
+ "> > > path for DAX filesystems, use the same direct_IO path for both DAX\n"
+ "> > > and\n"
+ "> > > direct_io iocbs, but use the flags to identify when we are in\n"
+ "> > > O_DIRECT\n"
+ "> > > mode vs non O_DIRECT with DAX, and for O_DIRECT, use the\n"
+ "> > > conventional\n"
+ "> > > direct_IO path instead of DAX.\n"
+ "> > > \n"
+ "> > Really? What are your thinking here?\n"
+ "> > \n"
+ "> > What about all the current users of O_DIRECT, you have just made\n"
+ "> > them\n"
+ "> > 4 times slower and \"less concurrent*\" then \"buffred io\" users. Since\n"
+ "> > direct_IO path will queue an IO request and all.\n"
+ "> > (And if it is not so slow then why do we need dax_do_io at all?\n"
+ "> > [Rhetorical])\n"
+ "> > \n"
+ "> > I hate it that you overload the semantics of a known and expected\n"
+ "> > O_DIRECT flag, for special pmem quirks. This is an incompatible\n"
+ "> > and unrelated overload of the semantics of O_DIRECT.\n"
+ "> Agreed - makig O_DIRECT less direct than not having it is plain\n"
+ "> stupid,\n"
+ "> and I somehow missed this initially.\n"
+ "\n"
+ "How is it any 'less direct'? All it does now is follow the blockdev\n"
+ "O_DIRECT path. There still isn't any page cache involved..\n"
+ "\n"
+ "> \n"
+ "> This whole DAX story turns into a major nightmare, and I fear all our\n"
+ "> hodge podge tweaks to the semantics aren't helping it.\n"
+ "> \n"
+ "> It seems like we simply need an explicit O_DAX for the read/write\n"
+ "> bypass if can't sort out the semantics (error, writer synchronization)\n"
+ "> just as we need a special flag for MMAP..\n"
+ "_______________________________________________\n"
+ "xfs mailing list\n"
+ "xfs@oss.sgi.com\n"
+ http://oss.sgi.com/mailman/listinfo/xfs
 
-c1154ece4ce3ce266c0a3a6b9b7c719810a35a7dca5ddfaf6eabf23ffe4abf04
+09d098b7a2e0200ecc4229297fd33a43b5ca871c3b4c4bcb205f146ef1bf1074
