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

diff --git a/a/1.txt b/N1/1.txt
index ea54898..50a53a5 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,40 +1,60 @@
-T24gV2VkLCAyMDE3LTAxLTE4IGF0IDEzOjMyIC0wODAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+
-IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0IDE6MDIgUE0sIERhcnJpY2sgSi4gV29uZw0KPiA8ZGFy
-cmljay53b25nQG9yYWNsZS5jb20+IHdyb3RlOg0KPiA+IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0
-IDAzOjM5OjE3UE0gLTA1MDAsIEplZmYgTW95ZXIgd3JvdGU6DQo+ID4gPiBKYW4gS2FyYSA8amFj
-a0BzdXNlLmN6PiB3cml0ZXM6DQo+ID4gPiANCj4gPiA+ID4gT24gVHVlIDE3LTAxLTE3IDE1OjE0
-OjIxLCBWaXNoYWwgVmVybWEgd3JvdGU6DQo+ID4gPiA+ID4gWW91ciBub3RlIG9uIHRoZSBvbmxp
-bmUgcmVwYWlyIGRvZXMgcmFpc2UgYW5vdGhlciB0YW5nZW50aWFsbHkNCj4gPiA+ID4gPiByZWxh
-dGVkDQo+ID4gPiA+ID4gdG9waWMuIEN1cnJlbnRseSwgaWYgdGhlcmUgYXJlIGJhZGJsb2Nrcywg
-d3JpdGVzIHZpYSB0aGUgYmlvDQo+ID4gPiA+ID4gc3VibWlzc2lvbg0KPiA+ID4gPiA+IHBhdGgg
-d2lsbCBjbGVhciB0aGUgZXJyb3IgKGlmIHRoZSBoYXJkd2FyZSBpcyBhYmxlIHRvIHJlbWFwDQo+
-ID4gPiA+ID4gdGhlIGJhZA0KPiA+ID4gPiA+IGxvY2F0aW9ucykuIEhvd2V2ZXIsIGlmIHRoZSBm
-aWxlc3lzdGVtIGlzIG1vdW50ZWQgZWl0aCBEQVgsDQo+ID4gPiA+ID4gZXZlbg0KPiA+ID4gPiA+
-IG5vbi1tbWFwIG9wZXJhdGlvbnMgLSByZWFkKCkgYW5kIHdyaXRlKCkgd2lsbCBnbyB0aHJvdWdo
-IHRoZQ0KPiA+ID4gPiA+IGRheCBwYXRocw0KPiA+ID4gPiA+IChkYXhfZG9faW8oKSkuIFdlIGhh
-dmVuJ3QgZm91bmQgYSBnb29kL2FncmVlYWJsZSB3YXkgdG8NCj4gPiA+ID4gPiBwZXJmb3JtDQo+
-ID4gPiA+ID4gZXJyb3ItY2xlYXJpbmcgaW4gdGhpcyBjYXNlLiBTbyBjdXJyZW50bHksIGlmIGEg
-ZGF4IG1vdW50ZWQNCj4gPiA+ID4gPiBmaWxlc3lzdGVtDQo+ID4gPiA+ID4gaGFzIGJhZGJsb2Nr
-cywgdGhlIG9ubHkgd2F5IHRvIGNsZWFyIHRob3NlIGJhZGJsb2NrcyBpcyB0bw0KPiA+ID4gPiA+
-IG1vdW50IGl0DQo+ID4gPiA+ID4gd2l0aG91dCBEQVgsIGFuZCBvdmVyd3JpdGUvemVybyB0aGUg
-YmFkIGxvY2F0aW9ucy4gVGhpcyBpcyBhDQo+ID4gPiA+ID4gcHJldHR5DQo+ID4gPiA+ID4gdGVy
-cmlibGUgdXNlciBleHBlcmllbmNlLCBhbmQgSSdtIGhvcGluZyB0aGlzIGNhbiBiZSBzb2x2ZWQg
-aW4NCj4gPiA+ID4gPiBhIGJldHRlcg0KPiA+ID4gPiA+IHdheS4NCj4gPiA+ID4gDQo+ID4gPiA+
-IFBsZWFzZSByZW1pbmQgbWUsIHdoYXQgaXMgdGhlIHByb2JsZW0gd2l0aCBEQVggY29kZSBkb2lu
-Zw0KPiA+ID4gPiBuZWNlc3Nhcnkgd29yayB0bw0KPiA+ID4gPiBjbGVhciB0aGUgZXJyb3Igd2hl
-biBpdCBnZXRzIEVJTyBmcm9tIG1lbWNweSBvbiB3cml0ZT8NCj4gPiA+IA0KPiA+ID4gWW91IHdv
-bid0IGdldCBhbiBNQ0UgZm9yIGEgc3RvcmU7wqDCoG9ubHkgbG9hZHMgZ2VuZXJhdGUgdGhlbS4N
-Cj4gPiA+IA0KPiA+ID4gV29uJ3QgZmFsbG9jYXRlIEZMX1pFUk9fUkFOR0UgY2xlYXIgYmFkIGJs
-b2NrcyB3aGVuIG1vdW50ZWQgd2l0aA0KPiA+ID4gLW8gZGF4Pw0KPiA+IA0KPiA+IE5vdCBuZWNl
-c3NhcmlseTsgWEZTIHVzdWFsbHkgaW1wbGVtZW50cyB0aGlzIGJ5IHB1bmNoaW5nIG91dCB0aGUN
-Cj4gPiByYW5nZQ0KPiA+IGFuZCB0aGVuIHJlYWxsb2NhdGluZyBpdCBhcyB1bndyaXR0ZW4gYmxv
-Y2tzLg0KPiA+IA0KPiANCj4gVGhhdCBkb2VzIGNsZWFyIHRoZSBlcnJvciBiZWNhdXNlIHRoZSB1
-bndyaXR0ZW4gYmxvY2tzIGFyZSB6ZXJvZWQgYW5kDQo+IGVycm9ycyBjbGVhcmVkIHdoZW4gdGhl
-eSBiZWNvbWUgYWxsb2NhdGVkIGFnYWluLg0KDQpZZXMsIHRoZSBwcm9ibGVtIHdhcyB0aGF0IHdy
-aXRlcyB3b24ndCBjbGVhciBlcnJvcnMuIHplcm9pbmcgdGhyb3VnaA0KZWl0aGVyIGhvbGUtcHVu
-Y2gsIHRydW5jYXRlLCB1bmxpbmtpbmcgdGhlIGZpbGUgc2hvdWxkIGFsbCB3b3JrDQooYXNzdW1p
-bmcgdGhlIGhvbGUtcHVuY2ggb3IgdHJ1bmNhdGUgcmFuZ2VzIHdob2xseSBjb250YWluIHRoZQ0K
-J2JhZGJsb2NrJyBzZWN0b3IpLg0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
-X19fX19fX19fX19fX19fX18NCj4gTGludXgtbnZkaW1tIG1haWxpbmcgbGlzdA0KPiBMaW51eC1u
-dmRpbW1AbGlzdHMuMDEub3JnDQo+IGh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGlu
-Zm8vbGludXgtbnZkaW1t
+On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote:
+> On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong
+> <darrick.wong@oracle.com> wrote:
+> > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:
+> > > Jan Kara <jack@suse.cz> writes:
+> > > 
+> > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote:
+> > > > > Your note on the online repair does raise another tangentially
+> > > > > related
+> > > > > topic. Currently, if there are badblocks, writes via the bio
+> > > > > submission
+> > > > > path will clear the error (if the hardware is able to remap
+> > > > > the bad
+> > > > > locations). However, if the filesystem is mounted eith DAX,
+> > > > > even
+> > > > > non-mmap operations - read() and write() will go through the
+> > > > > dax paths
+> > > > > (dax_do_io()). We haven't found a good/agreeable way to
+> > > > > perform
+> > > > > error-clearing in this case. So currently, if a dax mounted
+> > > > > filesystem
+> > > > > has badblocks, the only way to clear those badblocks is to
+> > > > > mount it
+> > > > > without DAX, and overwrite/zero the bad locations. This is a
+> > > > > pretty
+> > > > > terrible user experience, and I'm hoping this can be solved in
+> > > > > a better
+> > > > > way.
+> > > > 
+> > > > Please remind me, what is the problem with DAX code doing
+> > > > necessary work to
+> > > > clear the error when it gets EIO from memcpy on write?
+> > > 
+> > > You won't get an MCE for a store;  only loads generate them.
+> > > 
+> > > Won't fallocate FL_ZERO_RANGE clear bad blocks when mounted with
+> > > -o dax?
+> > 
+> > Not necessarily; XFS usually implements this by punching out the
+> > range
+> > and then reallocating it as unwritten blocks.
+> > 
+> 
+> That does clear the error because the unwritten blocks are zeroed and
+> errors cleared when they become allocated again.
+
+Yes, the problem was that writes won't clear errors. zeroing through
+either hole-punch, truncate, unlinking the file should all work
+(assuming the hole-punch or truncate ranges wholly contain the
+'badblock' sector).
+
+
+> _______________________________________________
+> Linux-nvdimm mailing list
+> Linux-nvdimm@lists.01.org
+> https://lists.01.org/mailman/listinfo/linux-nvdimm
+_______________________________________________
+Linux-nvdimm mailing list
+Linux-nvdimm@lists.01.org
+https://lists.01.org/mailman/listinfo/linux-nvdimm
diff --git a/a/content_digest b/N1/content_digest
index dd6dd88..0338188 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -9,60 +9,81 @@
  "ref\0x49r3406r2i.fsf@segfault.boston.devel.redhat.com\0"
  "ref\020170118210241.GE10498@birch.djwong.org\0"
  "ref\0CAPcyv4hd7bpCa7d9msX0Y8gLz7WsqXT3VExQwwLuAcsmMxVTPg@mail.gmail.com\0"
- "From\0Verma, Vishal L <vishal.l.verma@intel.com>\0"
+ "ref\0CAPcyv4hd7bpCa7d9msX0Y8gLz7WsqXT3VExQwwLuAcsmMxVTPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0"
+ "From\0Verma, Vishal L <vishal.l.verma-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0"
  "Subject\0Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems\0"
  "Date\0Wed, 18 Jan 2017 21:56:58 +0000\0"
  "To\0Williams"
-  Dan J <dan.j.williams@intel.com>
- " darrick.wong@oracle.com <darrick.wong@oracle.com>\0"
- "Cc\0Vyacheslav.Dubeyko@wdc.com <Vyacheslav.Dubeyko@wdc.com>"
-  jack@suse.cz <jack@suse.cz>
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
-  linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
-  lsf-pc@lists.linux-foundation.org <lsf-pc@lists.linux-foundation.org>
-  linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
- " slava@dubeyko.com <slava@dubeyko.com>\0"
+  Dan J <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+ " darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0"
+ "Cc\0jack-AlSwsSmVLrQ@public.gmane.org <jack-AlSwsSmVLrQ@public.gmane.org>"
+  Vyacheslav.Dubeyko-Sjgp3cTcYWE@public.gmane.org <Vyacheslav.Dubeyko-Sjgp3cTcYWE@public.gmane.org>
+  linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>
+  linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
+  slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
+  linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
+ " lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org <lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>\0"
  "\00:1\0"
  "b\0"
- "T24gV2VkLCAyMDE3LTAxLTE4IGF0IDEzOjMyIC0wODAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+\n"
- "IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0IDE6MDIgUE0sIERhcnJpY2sgSi4gV29uZw0KPiA8ZGFy\n"
- "cmljay53b25nQG9yYWNsZS5jb20+IHdyb3RlOg0KPiA+IE9uIFdlZCwgSmFuIDE4LCAyMDE3IGF0\n"
- "IDAzOjM5OjE3UE0gLTA1MDAsIEplZmYgTW95ZXIgd3JvdGU6DQo+ID4gPiBKYW4gS2FyYSA8amFj\n"
- "a0BzdXNlLmN6PiB3cml0ZXM6DQo+ID4gPiANCj4gPiA+ID4gT24gVHVlIDE3LTAxLTE3IDE1OjE0\n"
- "OjIxLCBWaXNoYWwgVmVybWEgd3JvdGU6DQo+ID4gPiA+ID4gWW91ciBub3RlIG9uIHRoZSBvbmxp\n"
- "bmUgcmVwYWlyIGRvZXMgcmFpc2UgYW5vdGhlciB0YW5nZW50aWFsbHkNCj4gPiA+ID4gPiByZWxh\n"
- "dGVkDQo+ID4gPiA+ID4gdG9waWMuIEN1cnJlbnRseSwgaWYgdGhlcmUgYXJlIGJhZGJsb2Nrcywg\n"
- "d3JpdGVzIHZpYSB0aGUgYmlvDQo+ID4gPiA+ID4gc3VibWlzc2lvbg0KPiA+ID4gPiA+IHBhdGgg\n"
- "d2lsbCBjbGVhciB0aGUgZXJyb3IgKGlmIHRoZSBoYXJkd2FyZSBpcyBhYmxlIHRvIHJlbWFwDQo+\n"
- "ID4gPiA+ID4gdGhlIGJhZA0KPiA+ID4gPiA+IGxvY2F0aW9ucykuIEhvd2V2ZXIsIGlmIHRoZSBm\n"
- "aWxlc3lzdGVtIGlzIG1vdW50ZWQgZWl0aCBEQVgsDQo+ID4gPiA+ID4gZXZlbg0KPiA+ID4gPiA+\n"
- "IG5vbi1tbWFwIG9wZXJhdGlvbnMgLSByZWFkKCkgYW5kIHdyaXRlKCkgd2lsbCBnbyB0aHJvdWdo\n"
- "IHRoZQ0KPiA+ID4gPiA+IGRheCBwYXRocw0KPiA+ID4gPiA+IChkYXhfZG9faW8oKSkuIFdlIGhh\n"
- "dmVuJ3QgZm91bmQgYSBnb29kL2FncmVlYWJsZSB3YXkgdG8NCj4gPiA+ID4gPiBwZXJmb3JtDQo+\n"
- "ID4gPiA+ID4gZXJyb3ItY2xlYXJpbmcgaW4gdGhpcyBjYXNlLiBTbyBjdXJyZW50bHksIGlmIGEg\n"
- "ZGF4IG1vdW50ZWQNCj4gPiA+ID4gPiBmaWxlc3lzdGVtDQo+ID4gPiA+ID4gaGFzIGJhZGJsb2Nr\n"
- "cywgdGhlIG9ubHkgd2F5IHRvIGNsZWFyIHRob3NlIGJhZGJsb2NrcyBpcyB0bw0KPiA+ID4gPiA+\n"
- "IG1vdW50IGl0DQo+ID4gPiA+ID4gd2l0aG91dCBEQVgsIGFuZCBvdmVyd3JpdGUvemVybyB0aGUg\n"
- "YmFkIGxvY2F0aW9ucy4gVGhpcyBpcyBhDQo+ID4gPiA+ID4gcHJldHR5DQo+ID4gPiA+ID4gdGVy\n"
- "cmlibGUgdXNlciBleHBlcmllbmNlLCBhbmQgSSdtIGhvcGluZyB0aGlzIGNhbiBiZSBzb2x2ZWQg\n"
- "aW4NCj4gPiA+ID4gPiBhIGJldHRlcg0KPiA+ID4gPiA+IHdheS4NCj4gPiA+ID4gDQo+ID4gPiA+\n"
- "IFBsZWFzZSByZW1pbmQgbWUsIHdoYXQgaXMgdGhlIHByb2JsZW0gd2l0aCBEQVggY29kZSBkb2lu\n"
- "Zw0KPiA+ID4gPiBuZWNlc3Nhcnkgd29yayB0bw0KPiA+ID4gPiBjbGVhciB0aGUgZXJyb3Igd2hl\n"
- "biBpdCBnZXRzIEVJTyBmcm9tIG1lbWNweSBvbiB3cml0ZT8NCj4gPiA+IA0KPiA+ID4gWW91IHdv\n"
- "bid0IGdldCBhbiBNQ0UgZm9yIGEgc3RvcmU7wqDCoG9ubHkgbG9hZHMgZ2VuZXJhdGUgdGhlbS4N\n"
- "Cj4gPiA+IA0KPiA+ID4gV29uJ3QgZmFsbG9jYXRlIEZMX1pFUk9fUkFOR0UgY2xlYXIgYmFkIGJs\n"
- "b2NrcyB3aGVuIG1vdW50ZWQgd2l0aA0KPiA+ID4gLW8gZGF4Pw0KPiA+IA0KPiA+IE5vdCBuZWNl\n"
- "c3NhcmlseTsgWEZTIHVzdWFsbHkgaW1wbGVtZW50cyB0aGlzIGJ5IHB1bmNoaW5nIG91dCB0aGUN\n"
- "Cj4gPiByYW5nZQ0KPiA+IGFuZCB0aGVuIHJlYWxsb2NhdGluZyBpdCBhcyB1bndyaXR0ZW4gYmxv\n"
- "Y2tzLg0KPiA+IA0KPiANCj4gVGhhdCBkb2VzIGNsZWFyIHRoZSBlcnJvciBiZWNhdXNlIHRoZSB1\n"
- "bndyaXR0ZW4gYmxvY2tzIGFyZSB6ZXJvZWQgYW5kDQo+IGVycm9ycyBjbGVhcmVkIHdoZW4gdGhl\n"
- "eSBiZWNvbWUgYWxsb2NhdGVkIGFnYWluLg0KDQpZZXMsIHRoZSBwcm9ibGVtIHdhcyB0aGF0IHdy\n"
- "aXRlcyB3b24ndCBjbGVhciBlcnJvcnMuIHplcm9pbmcgdGhyb3VnaA0KZWl0aGVyIGhvbGUtcHVu\n"
- "Y2gsIHRydW5jYXRlLCB1bmxpbmtpbmcgdGhlIGZpbGUgc2hvdWxkIGFsbCB3b3JrDQooYXNzdW1p\n"
- "bmcgdGhlIGhvbGUtcHVuY2ggb3IgdHJ1bmNhdGUgcmFuZ2VzIHdob2xseSBjb250YWluIHRoZQ0K\n"
- "J2JhZGJsb2NrJyBzZWN0b3IpLg0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f\n"
- "X19fX19fX19fX19fX19fX18NCj4gTGludXgtbnZkaW1tIG1haWxpbmcgbGlzdA0KPiBMaW51eC1u\n"
- "dmRpbW1AbGlzdHMuMDEub3JnDQo+IGh0dHBzOi8vbGlzdHMuMDEub3JnL21haWxtYW4vbGlzdGlu\n"
- Zm8vbGludXgtbnZkaW1t
+ "On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote:\n"
+ "> On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong\n"
+ "> <darrick.wong@oracle.com> wrote:\n"
+ "> > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:\n"
+ "> > > Jan Kara <jack@suse.cz> writes:\n"
+ "> > > \n"
+ "> > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote:\n"
+ "> > > > > Your note on the online repair does raise another tangentially\n"
+ "> > > > > related\n"
+ "> > > > > topic. Currently, if there are badblocks, writes via the bio\n"
+ "> > > > > submission\n"
+ "> > > > > path will clear the error (if the hardware is able to remap\n"
+ "> > > > > the bad\n"
+ "> > > > > locations). However, if the filesystem is mounted eith DAX,\n"
+ "> > > > > even\n"
+ "> > > > > non-mmap operations - read() and write() will go through the\n"
+ "> > > > > dax paths\n"
+ "> > > > > (dax_do_io()). We haven't found a good/agreeable way to\n"
+ "> > > > > perform\n"
+ "> > > > > error-clearing in this case. So currently, if a dax mounted\n"
+ "> > > > > filesystem\n"
+ "> > > > > has badblocks, the only way to clear those badblocks is to\n"
+ "> > > > > mount it\n"
+ "> > > > > without DAX, and overwrite/zero the bad locations. This is a\n"
+ "> > > > > pretty\n"
+ "> > > > > terrible user experience, and I'm hoping this can be solved in\n"
+ "> > > > > a better\n"
+ "> > > > > way.\n"
+ "> > > > \n"
+ "> > > > Please remind me, what is the problem with DAX code doing\n"
+ "> > > > necessary work to\n"
+ "> > > > clear the error when it gets EIO from memcpy on write?\n"
+ "> > > \n"
+ "> > > You won't get an MCE for a store;\302\240\302\240only loads generate them.\n"
+ "> > > \n"
+ "> > > Won't fallocate FL_ZERO_RANGE clear bad blocks when mounted with\n"
+ "> > > -o dax?\n"
+ "> > \n"
+ "> > Not necessarily; XFS usually implements this by punching out the\n"
+ "> > range\n"
+ "> > and then reallocating it as unwritten blocks.\n"
+ "> > \n"
+ "> \n"
+ "> That does clear the error because the unwritten blocks are zeroed and\n"
+ "> errors cleared when they become allocated again.\n"
+ "\n"
+ "Yes, the problem was that writes won't clear errors. zeroing through\n"
+ "either hole-punch, truncate, unlinking the file should all work\n"
+ "(assuming the hole-punch or truncate ranges wholly contain the\n"
+ "'badblock' sector).\n"
+ "\n"
+ "\n"
+ "> _______________________________________________\n"
+ "> Linux-nvdimm mailing list\n"
+ "> Linux-nvdimm@lists.01.org\n"
+ "> https://lists.01.org/mailman/listinfo/linux-nvdimm\n"
+ "_______________________________________________\n"
+ "Linux-nvdimm mailing list\n"
+ "Linux-nvdimm@lists.01.org\n"
+ https://lists.01.org/mailman/listinfo/linux-nvdimm
 
-94538d55ff2361f94764636b72c8da8f16ce1cf27786c21927733905d569f92a
+b20a9cb6ddcbfd331233e849f413c094d2fcd4e3bb98af9fd90ce1c6319203e8
