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

diff --git a/a/1.txt b/N1/1.txt
index 2d2142d..acb4ab4 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,55 +1,71 @@
-T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA4OjE1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+
-IE9uIFRodSwgTWF5IDUsIDIwMTYgYXQgNzoyNCBBTSwgQ2hyaXN0b3BoIEhlbGx3aWcgPGhjaEBp
-bmZyYWRlYWQub3JnPg0KPiB3cm90ZToNCj4gPiANCj4gPiBPbiBNb24sIE1heSAwMiwgMjAxNiBh
-dCAwNjo0MTo1MVBNICswMzAwLCBCb2F6IEhhcnJvc2ggd3JvdGU6DQo+ID4gPiANCj4gPiA+ID4g
-DQo+ID4gPiA+IEFsbCBJTyBpbiBhIGRheCBmaWxlc3lzdGVtIHVzZWQgdG8gZ28gdGhyb3VnaCBk
-YXhfZG9faW8sIHdoaWNoDQo+ID4gPiA+IGNhbm5vdA0KPiA+ID4gPiBoYW5kbGUgbWVkaWEgZXJy
-b3JzLCBhbmQgdGh1cyBjYW5ub3QgcHJvdmlkZSBhIHJlY292ZXJ5IHBhdGgNCj4gPiA+ID4gdGhh
-dCBjYW4NCj4gPiA+ID4gc2VuZCBhIHdyaXRlIHRocm91Z2ggdGhlIGRyaXZlciB0byBjbGVhciBl
-cnJvcnMuDQo+ID4gPiA+IA0KPiA+ID4gPiBBZGQgYSBuZXcgaW9jYiBmbGFnIGZvciBEQVgsIGFu
-ZCBzZXQgaXQgb25seSBmb3IgREFYIG1vdW50cy4gSW4NCj4gPiA+ID4gdGhlIElPDQo+ID4gPiA+
-IHBhdGggZm9yIERBWCBmaWxlc3lzdGVtcywgdXNlIHRoZSBzYW1lIGRpcmVjdF9JTyBwYXRoIGZv
-ciBib3RoDQo+ID4gPiA+IERBWCBhbmQNCj4gPiA+ID4gZGlyZWN0X2lvIGlvY2JzLCBidXQgdXNl
-IHRoZSBmbGFncyB0byBpZGVudGlmeSB3aGVuIHdlIGFyZSBpbg0KPiA+ID4gPiBPX0RJUkVDVA0K
-PiA+ID4gPiBtb2RlIHZzIG5vbiBPX0RJUkVDVCB3aXRoIERBWCwgYW5kIGZvciBPX0RJUkVDVCwg
-dXNlIHRoZQ0KPiA+ID4gPiBjb252ZW50aW9uYWwNCj4gPiA+ID4gZGlyZWN0X0lPIHBhdGggaW5z
-dGVhZCBvZiBEQVguDQo+ID4gPiA+IA0KPiA+ID4gUmVhbGx5PyBXaGF0IGFyZSB5b3VyIHRoaW5r
-aW5nIGhlcmU/DQo+ID4gPiANCj4gPiA+IFdoYXQgYWJvdXQgYWxsIHRoZSBjdXJyZW50IHVzZXJz
-IG9mIE9fRElSRUNULCB5b3UgaGF2ZSBqdXN0IG1hZGUNCj4gPiA+IHRoZW0NCj4gPiA+IDQgdGlt
-ZXMgc2xvd2VyIGFuZCAibGVzcyBjb25jdXJyZW50KiIgdGhlbiAiYnVmZnJlZCBpbyIgdXNlcnMu
-DQo+ID4gPiBTaW5jZQ0KPiA+ID4gZGlyZWN0X0lPIHBhdGggd2lsbCBxdWV1ZSBhbiBJTyByZXF1
-ZXN0IGFuZCBhbGwuDQo+ID4gPiAoQW5kIGlmIGl0IGlzIG5vdCBzbyBzbG93IHRoZW4gd2h5IGRv
-IHdlIG5lZWQgZGF4X2RvX2lvIGF0IGFsbD8NCj4gPiA+IFtSaGV0b3JpY2FsXSkNCj4gPiA+IA0K
-PiA+ID4gSSBoYXRlIGl0IHRoYXQgeW91IG92ZXJsb2FkIHRoZSBzZW1hbnRpY3Mgb2YgYSBrbm93
-biBhbmQgZXhwZWN0ZWQNCj4gPiA+IE9fRElSRUNUIGZsYWcsIGZvciBzcGVjaWFsIHBtZW0gcXVp
-cmtzLiBUaGlzIGlzIGFuIGluY29tcGF0aWJsZQ0KPiA+ID4gYW5kIHVucmVsYXRlZCBvdmVybG9h
-ZCBvZiB0aGUgc2VtYW50aWNzIG9mIE9fRElSRUNULg0KPiA+IEFncmVlZCAtIG1ha2lnIE9fRElS
-RUNUIGxlc3MgZGlyZWN0IHRoYW4gbm90IGhhdmluZyBpdCBpcyBwbGFpbg0KPiA+IHN0dXBpZCwN
-Cj4gPiBhbmQgSSBzb21laG93IG1pc3NlZCB0aGlzIGluaXRpYWxseS4NCj4gT2YgY291cnNlIEkg
-ZGlzYWdyZWUgYmVjYXVzZSBsaWtlIERhdmUgYXJndWVzIGluIHRoZSBtc3luYyBjYXNlIHdlDQo+
-IHNob3VsZCBkbyB0aGUgY29ycmVjdCB0aGluZyBmaXJzdCBhbmQgbWFrZSBpdCBmYXN0IGxhdGVy
-LCBidXQgYWxzbw0KPiBsaWtlIERhdmUgdGhpcyBhcmd1aW5nIGluIGNpcmNsZXMgaXMgZ2V0dGlu
-ZyB0aXJlc29tZS4NCj4gDQo+ID4gDQo+ID4gVGhpcyB3aG9sZSBEQVggc3RvcnkgdHVybnMgaW50
-byBhIG1ham9yIG5pZ2h0bWFyZSwgYW5kIEkgZmVhciBhbGwNCj4gPiBvdXINCj4gPiBob2RnZSBw
-b2RnZSB0d2Vha3MgdG8gdGhlIHNlbWFudGljcyBhcmVuJ3QgaGVscGluZyBpdC4NCj4gPiANCj4g
-PiBJdCBzZWVtcyBsaWtlIHdlIHNpbXBseSBuZWVkIGFuIGV4cGxpY2l0IE9fREFYIGZvciB0aGUg
-cmVhZC93cml0ZQ0KPiA+IGJ5cGFzcyBpZiBjYW4ndCBzb3J0IG91dCB0aGUgc2VtYW50aWNzIChl
-cnJvciwgd3JpdGVyDQo+ID4gc3luY2hyb25pemF0aW9uKQ0KPiA+IGp1c3QgYXMgd2UgbmVlZCBh
-IHNwZWNpYWwgZmxhZyBmb3IgTU1BUC4NCj4gSSBkb24ndCBzZWUgaG93IE9fREFYIG1ha2VzIHRo
-aXMgc2l0dWF0aW9uIGJldHRlciBpZiB0aGUgZ29hbCBpcyB0bw0KPiBhY2NlbGVyYXRlIHVubW9k
-aWZpZWQgYXBwbGljYXRpb25zLi4uDQo+IA0KPiBWaXNoYWwsIGF0IGxlYXN0IHRoZSAiZGVsZXRl
-IGEgZmlsZSB3aXRoIGEgYmFkYmxvY2siIG1vZGVsIHdpbGwgc3RpbGwNCj4gd29yayBmb3IgaW1w
-bGljaXRseSBjbGVhcmluZyBlcnJvcnMgd2l0aCB5b3VyIGNoYW5nZXMgdG8gc3RvcCBkb2luZw0K
-PiBibG9jayBjbGVhcmluZyBpbiBmcy9kYXguYy7CoMKgVGhpcyBjb21iaW5lZCB3aXRoIGEgbmV3
-IC1FQkFEQkxPQ0sgKGFzDQo+IERhdmUgc3VnZ2VzdHMpIGFuZCBleHBsaWNpdCBsb2dnaW5nIG9m
-IEkvT3MgdGhhdCBmYWlsIGZvciB0aGlzIHJlYXNvbg0KPiBhdCBsZWFzdCBnaXZlcyBhIGNoYW5j
-ZSB0byBjb21tdW5pY2F0ZSBlcnJvcnMgaW4gZmlsZXMgdG8gc3VpdGFibHkNCj4gYXdhcmUgYXBw
-bGljYXRpb25zIC8gZW52aXJvbm1lbnRzLg0KDQpBZ3JlZWQgLSBJJ2xsIHNlbmQgb3V0IGEgc2Vy
-aWVzIHRoYXQgaGFzIGp1c3QgdGhlIHplcm9pbmcgY2hhbmdlcywgYW5kDQpkcm9wIHRoZSBkYXhf
-aW8gZmFsbGJhY2svT19ESVJFQ1QgdHdlYWsgZm9yIG5vdyB3aGlsZSB3ZSBmaWd1cmUgb3V0IHRo
-ZQ0KcmlnaHQgdGhpbmcgdG8gZG8uIFRoYXQgc2hvdWxkIGdldCB1cyB0byBhIHBsYWNlIHdoZXJl
-IHdlIHN0aWxsIGhhdmUgZGF4DQppbiB0aGUgcHJlc2VuY2Ugb2YgZXJyb3JzLCBhbmQgaGF2ZSBf
-YV8gcGF0aCBmb3IgcmVjb3ZlcnkuDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
-X19fX19fX19fX19fX19fX18NCj4gTGludXgtbnZkaW1tIG1haWxpbmcgbGlzdA0KPiBMaW51eC1u
-dmRpbW1AbGlzdHMuMDEub3JnDQo+IGh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGlu
-Zm8vbGludXgtbnZkaW1t
+On Thu, 2016-05-05 at 08:15 -0700, Dan Williams wrote:
+> On Thu, May 5, 2016 at 7:24 AM, Christoph Hellwig <hch@infradead.org>
+> 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.
+> 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.
+> 
+> > 
+> > 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.
+> I don't see how O_DAX makes this situation better if the goal is to
+> accelerate unmodified applications...
+> 
+> Vishal, at least the "delete a file with a badblock" model will still
+> work for implicitly clearing errors with your changes to stop doing
+> block clearing in fs/dax.c.Â Â This combined with a new -EBADBLOCK (as
+> Dave suggests) and explicit logging of I/Os that fail for this reason
+> at least gives a chance to communicate errors in files to suitably
+> aware applications / environments.
+
+Agreed - I'll send out a series that has just the zeroing changes, and
+drop the dax_io fallback/O_DIRECT tweak for now while we figure out the
+right thing to do. That should get us to a place where we still have dax
+in the presence of errors, and have _a_ path for recovery.
+
+> _______________________________________________
+> Linux-nvdimm mailing list
+> Linux-nvdimm@lists.01.org
+> https://lists.01.org/mailman/listinfo/linux-nvdimmN‹§²æìr¸›zÇ§u©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
diff --git a/a/content_digest b/N1/content_digest
index 3bbdb7c..f893f73 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -24,60 +24,76 @@
  " matthew@wil.cx <matthew@wil.cx>\0"
  "\00:1\0"
  "b\0"
- "T24gVGh1LCAyMDE2LTA1LTA1IGF0IDA4OjE1IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+\n"
- "IE9uIFRodSwgTWF5IDUsIDIwMTYgYXQgNzoyNCBBTSwgQ2hyaXN0b3BoIEhlbGx3aWcgPGhjaEBp\n"
- "bmZyYWRlYWQub3JnPg0KPiB3cm90ZToNCj4gPiANCj4gPiBPbiBNb24sIE1heSAwMiwgMjAxNiBh\n"
- "dCAwNjo0MTo1MVBNICswMzAwLCBCb2F6IEhhcnJvc2ggd3JvdGU6DQo+ID4gPiANCj4gPiA+ID4g\n"
- "DQo+ID4gPiA+IEFsbCBJTyBpbiBhIGRheCBmaWxlc3lzdGVtIHVzZWQgdG8gZ28gdGhyb3VnaCBk\n"
- "YXhfZG9faW8sIHdoaWNoDQo+ID4gPiA+IGNhbm5vdA0KPiA+ID4gPiBoYW5kbGUgbWVkaWEgZXJy\n"
- "b3JzLCBhbmQgdGh1cyBjYW5ub3QgcHJvdmlkZSBhIHJlY292ZXJ5IHBhdGgNCj4gPiA+ID4gdGhh\n"
- "dCBjYW4NCj4gPiA+ID4gc2VuZCBhIHdyaXRlIHRocm91Z2ggdGhlIGRyaXZlciB0byBjbGVhciBl\n"
- "cnJvcnMuDQo+ID4gPiA+IA0KPiA+ID4gPiBBZGQgYSBuZXcgaW9jYiBmbGFnIGZvciBEQVgsIGFu\n"
- "ZCBzZXQgaXQgb25seSBmb3IgREFYIG1vdW50cy4gSW4NCj4gPiA+ID4gdGhlIElPDQo+ID4gPiA+\n"
- "IHBhdGggZm9yIERBWCBmaWxlc3lzdGVtcywgdXNlIHRoZSBzYW1lIGRpcmVjdF9JTyBwYXRoIGZv\n"
- "ciBib3RoDQo+ID4gPiA+IERBWCBhbmQNCj4gPiA+ID4gZGlyZWN0X2lvIGlvY2JzLCBidXQgdXNl\n"
- "IHRoZSBmbGFncyB0byBpZGVudGlmeSB3aGVuIHdlIGFyZSBpbg0KPiA+ID4gPiBPX0RJUkVDVA0K\n"
- "PiA+ID4gPiBtb2RlIHZzIG5vbiBPX0RJUkVDVCB3aXRoIERBWCwgYW5kIGZvciBPX0RJUkVDVCwg\n"
- "dXNlIHRoZQ0KPiA+ID4gPiBjb252ZW50aW9uYWwNCj4gPiA+ID4gZGlyZWN0X0lPIHBhdGggaW5z\n"
- "dGVhZCBvZiBEQVguDQo+ID4gPiA+IA0KPiA+ID4gUmVhbGx5PyBXaGF0IGFyZSB5b3VyIHRoaW5r\n"
- "aW5nIGhlcmU/DQo+ID4gPiANCj4gPiA+IFdoYXQgYWJvdXQgYWxsIHRoZSBjdXJyZW50IHVzZXJz\n"
- "IG9mIE9fRElSRUNULCB5b3UgaGF2ZSBqdXN0IG1hZGUNCj4gPiA+IHRoZW0NCj4gPiA+IDQgdGlt\n"
- "ZXMgc2xvd2VyIGFuZCAibGVzcyBjb25jdXJyZW50KiIgdGhlbiAiYnVmZnJlZCBpbyIgdXNlcnMu\n"
- "DQo+ID4gPiBTaW5jZQ0KPiA+ID4gZGlyZWN0X0lPIHBhdGggd2lsbCBxdWV1ZSBhbiBJTyByZXF1\n"
- "ZXN0IGFuZCBhbGwuDQo+ID4gPiAoQW5kIGlmIGl0IGlzIG5vdCBzbyBzbG93IHRoZW4gd2h5IGRv\n"
- "IHdlIG5lZWQgZGF4X2RvX2lvIGF0IGFsbD8NCj4gPiA+IFtSaGV0b3JpY2FsXSkNCj4gPiA+IA0K\n"
- "PiA+ID4gSSBoYXRlIGl0IHRoYXQgeW91IG92ZXJsb2FkIHRoZSBzZW1hbnRpY3Mgb2YgYSBrbm93\n"
- "biBhbmQgZXhwZWN0ZWQNCj4gPiA+IE9fRElSRUNUIGZsYWcsIGZvciBzcGVjaWFsIHBtZW0gcXVp\n"
- "cmtzLiBUaGlzIGlzIGFuIGluY29tcGF0aWJsZQ0KPiA+ID4gYW5kIHVucmVsYXRlZCBvdmVybG9h\n"
- "ZCBvZiB0aGUgc2VtYW50aWNzIG9mIE9fRElSRUNULg0KPiA+IEFncmVlZCAtIG1ha2lnIE9fRElS\n"
- "RUNUIGxlc3MgZGlyZWN0IHRoYW4gbm90IGhhdmluZyBpdCBpcyBwbGFpbg0KPiA+IHN0dXBpZCwN\n"
- "Cj4gPiBhbmQgSSBzb21laG93IG1pc3NlZCB0aGlzIGluaXRpYWxseS4NCj4gT2YgY291cnNlIEkg\n"
- "ZGlzYWdyZWUgYmVjYXVzZSBsaWtlIERhdmUgYXJndWVzIGluIHRoZSBtc3luYyBjYXNlIHdlDQo+\n"
- "IHNob3VsZCBkbyB0aGUgY29ycmVjdCB0aGluZyBmaXJzdCBhbmQgbWFrZSBpdCBmYXN0IGxhdGVy\n"
- "LCBidXQgYWxzbw0KPiBsaWtlIERhdmUgdGhpcyBhcmd1aW5nIGluIGNpcmNsZXMgaXMgZ2V0dGlu\n"
- "ZyB0aXJlc29tZS4NCj4gDQo+ID4gDQo+ID4gVGhpcyB3aG9sZSBEQVggc3RvcnkgdHVybnMgaW50\n"
- "byBhIG1ham9yIG5pZ2h0bWFyZSwgYW5kIEkgZmVhciBhbGwNCj4gPiBvdXINCj4gPiBob2RnZSBw\n"
- "b2RnZSB0d2Vha3MgdG8gdGhlIHNlbWFudGljcyBhcmVuJ3QgaGVscGluZyBpdC4NCj4gPiANCj4g\n"
- "PiBJdCBzZWVtcyBsaWtlIHdlIHNpbXBseSBuZWVkIGFuIGV4cGxpY2l0IE9fREFYIGZvciB0aGUg\n"
- "cmVhZC93cml0ZQ0KPiA+IGJ5cGFzcyBpZiBjYW4ndCBzb3J0IG91dCB0aGUgc2VtYW50aWNzIChl\n"
- "cnJvciwgd3JpdGVyDQo+ID4gc3luY2hyb25pemF0aW9uKQ0KPiA+IGp1c3QgYXMgd2UgbmVlZCBh\n"
- "IHNwZWNpYWwgZmxhZyBmb3IgTU1BUC4NCj4gSSBkb24ndCBzZWUgaG93IE9fREFYIG1ha2VzIHRo\n"
- "aXMgc2l0dWF0aW9uIGJldHRlciBpZiB0aGUgZ29hbCBpcyB0bw0KPiBhY2NlbGVyYXRlIHVubW9k\n"
- "aWZpZWQgYXBwbGljYXRpb25zLi4uDQo+IA0KPiBWaXNoYWwsIGF0IGxlYXN0IHRoZSAiZGVsZXRl\n"
- "IGEgZmlsZSB3aXRoIGEgYmFkYmxvY2siIG1vZGVsIHdpbGwgc3RpbGwNCj4gd29yayBmb3IgaW1w\n"
- "bGljaXRseSBjbGVhcmluZyBlcnJvcnMgd2l0aCB5b3VyIGNoYW5nZXMgdG8gc3RvcCBkb2luZw0K\n"
- "PiBibG9jayBjbGVhcmluZyBpbiBmcy9kYXguYy7CoMKgVGhpcyBjb21iaW5lZCB3aXRoIGEgbmV3\n"
- "IC1FQkFEQkxPQ0sgKGFzDQo+IERhdmUgc3VnZ2VzdHMpIGFuZCBleHBsaWNpdCBsb2dnaW5nIG9m\n"
- "IEkvT3MgdGhhdCBmYWlsIGZvciB0aGlzIHJlYXNvbg0KPiBhdCBsZWFzdCBnaXZlcyBhIGNoYW5j\n"
- "ZSB0byBjb21tdW5pY2F0ZSBlcnJvcnMgaW4gZmlsZXMgdG8gc3VpdGFibHkNCj4gYXdhcmUgYXBw\n"
- "bGljYXRpb25zIC8gZW52aXJvbm1lbnRzLg0KDQpBZ3JlZWQgLSBJJ2xsIHNlbmQgb3V0IGEgc2Vy\n"
- "aWVzIHRoYXQgaGFzIGp1c3QgdGhlIHplcm9pbmcgY2hhbmdlcywgYW5kDQpkcm9wIHRoZSBkYXhf\n"
- "aW8gZmFsbGJhY2svT19ESVJFQ1QgdHdlYWsgZm9yIG5vdyB3aGlsZSB3ZSBmaWd1cmUgb3V0IHRo\n"
- "ZQ0KcmlnaHQgdGhpbmcgdG8gZG8uIFRoYXQgc2hvdWxkIGdldCB1cyB0byBhIHBsYWNlIHdoZXJl\n"
- "IHdlIHN0aWxsIGhhdmUgZGF4DQppbiB0aGUgcHJlc2VuY2Ugb2YgZXJyb3JzLCBhbmQgaGF2ZSBf\n"
- "YV8gcGF0aCBmb3IgcmVjb3ZlcnkuDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n"
- "X19fX19fX19fX19fX19fX18NCj4gTGludXgtbnZkaW1tIG1haWxpbmcgbGlzdA0KPiBMaW51eC1u\n"
- "dmRpbW1AbGlzdHMuMDEub3JnDQo+IGh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGlu\n"
- Zm8vbGludXgtbnZkaW1t
+ "On Thu, 2016-05-05 at 08:15 -0700, Dan Williams wrote:\n"
+ "> On Thu, May 5, 2016 at 7:24 AM, Christoph Hellwig <hch@infradead.org>\n"
+ "> wrote:\n"
+ "> > \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\n"
+ "> > > > that 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\n"
+ "> > > > DAX 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.\n"
+ "> > > 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"
+ "> 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"
+ "> \n"
+ "> > \n"
+ "> > This whole DAX story turns into a major nightmare, and I fear all\n"
+ "> > 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\n"
+ "> > synchronization)\n"
+ "> > just as we need a special flag for MMAP.\n"
+ "> I don't see how O_DAX makes this situation better if the goal is to\n"
+ "> accelerate unmodified applications...\n"
+ "> \n"
+ "> Vishal, at least the \"delete a file with a badblock\" model will still\n"
+ "> work for implicitly clearing errors with your changes to stop doing\n"
+ "> block clearing in fs/dax.c.\303\202\302\240\303\202\302\240This combined with a new -EBADBLOCK (as\n"
+ "> Dave suggests) and explicit logging of I/Os that fail for this reason\n"
+ "> at least gives a chance to communicate errors in files to suitably\n"
+ "> aware applications / environments.\n"
+ "\n"
+ "Agreed - I'll send out a series that has just the zeroing changes, and\n"
+ "drop the dax_io fallback/O_DIRECT tweak for now while we figure out the\n"
+ "right thing to do. That should get us to a place where we still have dax\n"
+ "in the presence of errors, and have _a_ path for recovery.\n"
+ "\n"
+ "> _______________________________________________\n"
+ "> Linux-nvdimm mailing list\n"
+ "> Linux-nvdimm@lists.01.org\n"
+ "> https://lists.01.org/mailman/listinfo/linux-nvdimmN\302\213\302\247\302\262\303\246\303\254r\302\270\302\233z\303\207\302\247u\302\251\302\236\302\262\303\206\302\240{\b\302\255\302\206\303\251\303\254\302\271\302\273\034\302\256&\303\236\302\226)\303\256\303\206i\302\242\302\236\303\230^n\302\207r\302\266\302\211\302\232\302\216\302\212\303\235\302\242j$\302\275\302\247$\302\242\302\270\005\302\242\302\271\302\250\302\255\303\250\302\247~\302\212'.)\303\256\303\204\303\203,y\303\250m\302\266\302\237\303\277\303\203\f%\302\212{\302\261\302\232j+\302\203\303\260\303\250\302\236\303\227\302\246j)Z\302\206\302\267\302\237"
 
-863b8001953a39c4925db052b8fa36715670609c792170c6e10583c3c0989052
+1706c8bfa0df05c85736ed589f05bc8b18f606a3dbd6e5a9bf42f46dd84abfc9
