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

diff --git a/a/1.txt b/N1/1.txt
index e66b660..7ccfd5c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,39 +1,53 @@
-VGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgYmFkYmxvY2tzLCB3aGVyZSB3ZSBjb25zdWx0
-IHRoZSBiYWRibG9ja3MNCmxpc3QgZm9yIGV2ZXJ5IElPIGluIHRoZSBibG9jayBkcml2ZXIgd29y
-a3MsIGFuZCBpcyBhIGxhc3Qgb3B0aW9uDQpmYWlsc2FmZSwgYnV0IGZyb20gYSB1c2VyIHBlcnNw
-ZWN0aXZlLCBpdCBpc24ndCB0aGUgZWFzaWVzdCBpbnRlcmZhY2UgdG8NCndvcmsgd2l0aC4NCg0K
-QSB3aGlsZSBiYWNrLCBEYXZlIENoaW5uZXIgaGFkIHN1Z2dlc3RlZCBhIG1vdmUgdG93YXJkcyBz
-bWFydGVyDQpoYW5kbGluZywgYW5kIEkgcG9zdGVkIGluaXRpYWwgUkZDIHBhdGNoZXMgWzFdLCBi
-dXQgc2luY2UgdGhlbiB0aGUgdG9waWMNCmhhc24ndCByZWFsbHkgbW92ZWQgZm9yd2FyZC4NCg0K
-SSdkIGxpa2UgdG8gcHJvcG9zZSBhbmQgaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIGZvbGxv
-d2luZyBuZXcNCmZ1bmN0aW9uYWxpdHk6DQoNCjEuIEZpbGVzeXN0ZW1zIGRldmVsb3AgYSBuYXRp
-dmUgcmVwcmVzZW50YXRpb24gb2YgYmFkYmxvY2tzLiBGb3INCmV4YW1wbGUsIGluIHhmcywgdGhp
-cyB3b3VsZCAocHJlc3VtYWJseSkgYmUgbGlua2VkIHRvIHRoZSByZXZlcnNlDQptYXBwaW5nIGJ0
-cmVlLiBUaGUgZmlsZXN5c3RlbSByZXByZXNlbnRhdGlvbiBoYXMgdGhlIHBvdGVudGlhbCB0byBi
-ZcKgDQptb3JlIGVmZmljaWVudCB0aGFuIHRoZSBibG9jayBkcml2ZXIgZG9pbmcgdGhlIGNoZWNr
-LCBhcyB0aGUgZnMgY2FuDQpjaGVjayB0aGUgSU8gaGFwcGVuaW5nIG9uIGEgZmlsZSBhZ2FpbnN0
-IGp1c3QgdGhhdCBmaWxlJ3MgcmFuZ2UuIEluDQpjb250cmFzdCwgdG9kYXksIHRoZSBibG9jayBk
-cml2ZXIgY2hlY2tzIGFnYWluc3QgdGhlIHdob2xlIGJsb2NrIGRldmljZQ0KcmFuZ2UgZm9yIGV2
-ZXJ5IElPLiBPbiBlbmNvdW50ZXJpbmcgYmFkYmxvY2tzLCB0aGUgZmlsZXN5c3RlbSBjYW4NCmdl
-bmVyYXRlIGEgYmV0dGVyIG5vdGlmaWNhdGlvbi9lcnJvciBtZXNzYWdlIHRoYXQgcG9pbnRzIHRo
-ZSB1c2VyIHRvwqANCihmaWxlLCBvZmZzZXQpIGFzIG9wcG9zZWQgdG8gdGhlIGJsb2NrIGRyaXZl
-ciwgd2hpY2ggY2FuIG9ubHkgcHJvdmlkZQ0KKGJsb2NrLWRldmljZSwgc2VjdG9yKS4NCg0KMi4g
-VGhlIGJsb2NrIGxheWVyIGFkZHMgYSBub3RpZmllciB0byBiYWRibG9jayBhZGRpdGlvbi9yZW1v
-dmFsDQpvcGVyYXRpb25zLCB3aGljaCB0aGUgZmlsZXN5c3RlbSBzdWJzY3JpYmVzIHRvLCBhbmQg
-dXNlcyB0byBtYWludGFpbiBpdHMNCmJhZGJsb2NrcyBhY2NvdW50aW5nLiAoVGhpcyBwYXJ0IGlz
-IGltcGxlbWVudGVkIGFzIGEgcHJvb2Ygb2YgY29uY2VwdCBpbg0KdGhlIFJGQyBtZW50aW9uZWQg
-YWJvdmUgWzFdKS4NCg0KMy4gVGhlIGZpbGVzeXN0ZW0gaGFzIGEgd2F5IG9mIHRlbGxpbmcgdGhl
-IGJsb2NrIGRyaXZlciAoYSBmbGFnPyBhDQpkaWZmZXJlbnQvbmV3IGludGVyZmFjZT8pIHRoYXQg
-aXQgaXMgcmVzcG9uc2libGUgZm9yIGJhZGJsb2NrIGNoZWNraW5nDQpzbyB0aGF0IHRoZSBkcml2
-ZXIgZG9lc24ndCBoYXZlIHRvIGRvIGl0cyBjaGVjay4gVGhlIGRyaXZlciBjaGVja2luZw0Kd2ls
-bCBoYXZlIHRvIHJlbWFpbiBpbiBwbGFjZSBhcyBhIGNhdGNoLWFsbCBmb3IgZmlsZXN5c3RlbXMv
-aW50ZXJmYWNlcw0KdGhhdCBkb24ndCBvciBhcmVuJ3QgY2FwYWJsZSBvZiBkb2luZyB0aGUgY2hl
-Y2tzIGF0IGEgaGlnaGVyIGxheWVyLg0KDQoNCkFkZGl0aW9uYWxseSwgSSBzYXcgc29tZSBkaXNj
-dXNzaW9uIGFib3V0IGxvZ2ljYWwgZGVwb3Agb24gdGhlIGxpc3RzDQphZ2FpbiwgYW5kIEkgd2Fz
-IGludm9sdmVkIHdpdGggZGlzY3Vzc2lvbnMgbGFzdCB5ZWFyIGFib3V0IGV4cGFuZGluZyB0aGUN
-CnRoZSBiYWRibG9ja3MgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoaXMgdXNlLiBJZiB0aGF0IGlzIGEg
-dG9waWMgYWdhaW4gdGhpcw0KeWVhciwgSSdkIGxpa2UgdG8gYmUgaW52b2x2ZWQgaW4gaXQgdG9v
-Lg0KDQpJJ20gYWxzbyBpbnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcgaW4gYW55IG90aGVyIHBt
-ZW0vTlZESU1NIHJlbGF0ZWQNCmRpc2N1c3Npb25zLg0KDQoNClRoYW5rIHlvdSwNCgktVmlzaGFs
-DQoNCg0KWzFdOiBodHRwOi8vd3d3LmxpbnV4LnNnaS5jb20vYXJjaGl2ZXMveGZzLzIwMTYtMDYv
-bXNnMDAyOTkuaHRtbA==
+The current implementation of badblocks, where we consult the badblocks
+list for every IO in the block driver works, and is a last option
+failsafe, but from a user perspective, it isn't the easiest interface to
+work with.
+
+A while back, Dave Chinner had suggested a move towards smarter
+handling, and I posted initial RFC patches [1], but since then the topic
+hasn't really moved forward.
+
+I'd like to propose and have a discussion about the following new
+functionality:
+
+1. Filesystems develop a native representation of badblocks. For
+example, in xfs, this would (presumably) be linked to the reverse
+mapping btree. The filesystem representation has the potential to be 
+more efficient than the block driver doing the check, as the fs can
+check the IO happening on a file against just that file's range. In
+contrast, today, the block driver checks against the whole block device
+range for every IO. On encountering badblocks, the filesystem can
+generate a better notification/error message that points the user to 
+(file, offset) as opposed to the block driver, which can only provide
+(block-device, sector).
+
+2. The block layer adds a notifier to badblock addition/removal
+operations, which the filesystem subscribes to, and uses to maintain its
+badblocks accounting. (This part is implemented as a proof of concept in
+the RFC mentioned above [1]).
+
+3. The filesystem has a way of telling the block driver (a flag? a
+different/new interface?) that it is responsible for badblock checking
+so that the driver doesn't have to do its check. The driver checking
+will have to remain in place as a catch-all for filesystems/interfaces
+that don't or aren't capable of doing the checks at a higher layer.
+
+
+Additionally, I saw some discussion about logical depop on the lists
+again, and I was involved with discussions last year about expanding the
+the badblocks infrastructure for this use. If that is a topic again this
+year, I'd like to be involved in it too.
+
+I'm also interested in participating in any other pmem/NVDIMM related
+discussions.
+
+
+Thank you,
+	-Vishal
+
+
+[1]: http://www.linux.sgi.com/archives/xfs/2016-06/msg00299.html
+_______________________________________________
+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 948b647..6a7c73f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,49 +2,63 @@
  "Subject\0[LSF/MM TOPIC] Badblocks checking/representation in filesystems\0"
  "Date\0Fri, 13 Jan 2017 21:40:26 +0000\0"
  "To\0lsf-pc@lists.linux-foundation.org <lsf-pc@lists.linux-foundation.org>\0"
- "Cc\0linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org>"
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
- " linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>\0"
+ "Cc\0linux-block@vger.kernel.org <linux-block@vger.kernel.org>"
+  linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
+ " linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org>\0"
  "\00:1\0"
  "b\0"
- "VGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgYmFkYmxvY2tzLCB3aGVyZSB3ZSBjb25zdWx0\n"
- "IHRoZSBiYWRibG9ja3MNCmxpc3QgZm9yIGV2ZXJ5IElPIGluIHRoZSBibG9jayBkcml2ZXIgd29y\n"
- "a3MsIGFuZCBpcyBhIGxhc3Qgb3B0aW9uDQpmYWlsc2FmZSwgYnV0IGZyb20gYSB1c2VyIHBlcnNw\n"
- "ZWN0aXZlLCBpdCBpc24ndCB0aGUgZWFzaWVzdCBpbnRlcmZhY2UgdG8NCndvcmsgd2l0aC4NCg0K\n"
- "QSB3aGlsZSBiYWNrLCBEYXZlIENoaW5uZXIgaGFkIHN1Z2dlc3RlZCBhIG1vdmUgdG93YXJkcyBz\n"
- "bWFydGVyDQpoYW5kbGluZywgYW5kIEkgcG9zdGVkIGluaXRpYWwgUkZDIHBhdGNoZXMgWzFdLCBi\n"
- "dXQgc2luY2UgdGhlbiB0aGUgdG9waWMNCmhhc24ndCByZWFsbHkgbW92ZWQgZm9yd2FyZC4NCg0K\n"
- "SSdkIGxpa2UgdG8gcHJvcG9zZSBhbmQgaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgdGhlIGZvbGxv\n"
- "d2luZyBuZXcNCmZ1bmN0aW9uYWxpdHk6DQoNCjEuIEZpbGVzeXN0ZW1zIGRldmVsb3AgYSBuYXRp\n"
- "dmUgcmVwcmVzZW50YXRpb24gb2YgYmFkYmxvY2tzLiBGb3INCmV4YW1wbGUsIGluIHhmcywgdGhp\n"
- "cyB3b3VsZCAocHJlc3VtYWJseSkgYmUgbGlua2VkIHRvIHRoZSByZXZlcnNlDQptYXBwaW5nIGJ0\n"
- "cmVlLiBUaGUgZmlsZXN5c3RlbSByZXByZXNlbnRhdGlvbiBoYXMgdGhlIHBvdGVudGlhbCB0byBi\n"
- "ZcKgDQptb3JlIGVmZmljaWVudCB0aGFuIHRoZSBibG9jayBkcml2ZXIgZG9pbmcgdGhlIGNoZWNr\n"
- "LCBhcyB0aGUgZnMgY2FuDQpjaGVjayB0aGUgSU8gaGFwcGVuaW5nIG9uIGEgZmlsZSBhZ2FpbnN0\n"
- "IGp1c3QgdGhhdCBmaWxlJ3MgcmFuZ2UuIEluDQpjb250cmFzdCwgdG9kYXksIHRoZSBibG9jayBk\n"
- "cml2ZXIgY2hlY2tzIGFnYWluc3QgdGhlIHdob2xlIGJsb2NrIGRldmljZQ0KcmFuZ2UgZm9yIGV2\n"
- "ZXJ5IElPLiBPbiBlbmNvdW50ZXJpbmcgYmFkYmxvY2tzLCB0aGUgZmlsZXN5c3RlbSBjYW4NCmdl\n"
- "bmVyYXRlIGEgYmV0dGVyIG5vdGlmaWNhdGlvbi9lcnJvciBtZXNzYWdlIHRoYXQgcG9pbnRzIHRo\n"
- "ZSB1c2VyIHRvwqANCihmaWxlLCBvZmZzZXQpIGFzIG9wcG9zZWQgdG8gdGhlIGJsb2NrIGRyaXZl\n"
- "ciwgd2hpY2ggY2FuIG9ubHkgcHJvdmlkZQ0KKGJsb2NrLWRldmljZSwgc2VjdG9yKS4NCg0KMi4g\n"
- "VGhlIGJsb2NrIGxheWVyIGFkZHMgYSBub3RpZmllciB0byBiYWRibG9jayBhZGRpdGlvbi9yZW1v\n"
- "dmFsDQpvcGVyYXRpb25zLCB3aGljaCB0aGUgZmlsZXN5c3RlbSBzdWJzY3JpYmVzIHRvLCBhbmQg\n"
- "dXNlcyB0byBtYWludGFpbiBpdHMNCmJhZGJsb2NrcyBhY2NvdW50aW5nLiAoVGhpcyBwYXJ0IGlz\n"
- "IGltcGxlbWVudGVkIGFzIGEgcHJvb2Ygb2YgY29uY2VwdCBpbg0KdGhlIFJGQyBtZW50aW9uZWQg\n"
- "YWJvdmUgWzFdKS4NCg0KMy4gVGhlIGZpbGVzeXN0ZW0gaGFzIGEgd2F5IG9mIHRlbGxpbmcgdGhl\n"
- "IGJsb2NrIGRyaXZlciAoYSBmbGFnPyBhDQpkaWZmZXJlbnQvbmV3IGludGVyZmFjZT8pIHRoYXQg\n"
- "aXQgaXMgcmVzcG9uc2libGUgZm9yIGJhZGJsb2NrIGNoZWNraW5nDQpzbyB0aGF0IHRoZSBkcml2\n"
- "ZXIgZG9lc24ndCBoYXZlIHRvIGRvIGl0cyBjaGVjay4gVGhlIGRyaXZlciBjaGVja2luZw0Kd2ls\n"
- "bCBoYXZlIHRvIHJlbWFpbiBpbiBwbGFjZSBhcyBhIGNhdGNoLWFsbCBmb3IgZmlsZXN5c3RlbXMv\n"
- "aW50ZXJmYWNlcw0KdGhhdCBkb24ndCBvciBhcmVuJ3QgY2FwYWJsZSBvZiBkb2luZyB0aGUgY2hl\n"
- "Y2tzIGF0IGEgaGlnaGVyIGxheWVyLg0KDQoNCkFkZGl0aW9uYWxseSwgSSBzYXcgc29tZSBkaXNj\n"
- "dXNzaW9uIGFib3V0IGxvZ2ljYWwgZGVwb3Agb24gdGhlIGxpc3RzDQphZ2FpbiwgYW5kIEkgd2Fz\n"
- "IGludm9sdmVkIHdpdGggZGlzY3Vzc2lvbnMgbGFzdCB5ZWFyIGFib3V0IGV4cGFuZGluZyB0aGUN\n"
- "CnRoZSBiYWRibG9ja3MgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoaXMgdXNlLiBJZiB0aGF0IGlzIGEg\n"
- "dG9waWMgYWdhaW4gdGhpcw0KeWVhciwgSSdkIGxpa2UgdG8gYmUgaW52b2x2ZWQgaW4gaXQgdG9v\n"
- "Lg0KDQpJJ20gYWxzbyBpbnRlcmVzdGVkIGluIHBhcnRpY2lwYXRpbmcgaW4gYW55IG90aGVyIHBt\n"
- "ZW0vTlZESU1NIHJlbGF0ZWQNCmRpc2N1c3Npb25zLg0KDQoNClRoYW5rIHlvdSwNCgktVmlzaGFs\n"
- "DQoNCg0KWzFdOiBodHRwOi8vd3d3LmxpbnV4LnNnaS5jb20vYXJjaGl2ZXMveGZzLzIwMTYtMDYv\n"
- bXNnMDAyOTkuaHRtbA==
+ "The current implementation of badblocks, where we consult the badblocks\n"
+ "list for every IO in the block driver works, and is a last option\n"
+ "failsafe, but from a user perspective, it isn't the easiest interface to\n"
+ "work with.\n"
+ "\n"
+ "A while back, Dave Chinner had suggested a move towards smarter\n"
+ "handling, and I posted initial RFC patches [1], but since then the topic\n"
+ "hasn't really moved forward.\n"
+ "\n"
+ "I'd like to propose and have a discussion about the following new\n"
+ "functionality:\n"
+ "\n"
+ "1. Filesystems develop a native representation of badblocks. For\n"
+ "example, in xfs, this would (presumably) be linked to the reverse\n"
+ "mapping btree. The filesystem representation has the potential to be\302\240\n"
+ "more efficient than the block driver doing the check, as the fs can\n"
+ "check the IO happening on a file against just that file's range. In\n"
+ "contrast, today, the block driver checks against the whole block device\n"
+ "range for every IO. On encountering badblocks, the filesystem can\n"
+ "generate a better notification/error message that points the user to\302\240\n"
+ "(file, offset) as opposed to the block driver, which can only provide\n"
+ "(block-device, sector).\n"
+ "\n"
+ "2. The block layer adds a notifier to badblock addition/removal\n"
+ "operations, which the filesystem subscribes to, and uses to maintain its\n"
+ "badblocks accounting. (This part is implemented as a proof of concept in\n"
+ "the RFC mentioned above [1]).\n"
+ "\n"
+ "3. The filesystem has a way of telling the block driver (a flag? a\n"
+ "different/new interface?) that it is responsible for badblock checking\n"
+ "so that the driver doesn't have to do its check. The driver checking\n"
+ "will have to remain in place as a catch-all for filesystems/interfaces\n"
+ "that don't or aren't capable of doing the checks at a higher layer.\n"
+ "\n"
+ "\n"
+ "Additionally, I saw some discussion about logical depop on the lists\n"
+ "again, and I was involved with discussions last year about expanding the\n"
+ "the badblocks infrastructure for this use. If that is a topic again this\n"
+ "year, I'd like to be involved in it too.\n"
+ "\n"
+ "I'm also interested in participating in any other pmem/NVDIMM related\n"
+ "discussions.\n"
+ "\n"
+ "\n"
+ "Thank you,\n"
+ "\t-Vishal\n"
+ "\n"
+ "\n"
+ "[1]: http://www.linux.sgi.com/archives/xfs/2016-06/msg00299.html\n"
+ "_______________________________________________\n"
+ "Linux-nvdimm mailing list\n"
+ "Linux-nvdimm@lists.01.org\n"
+ https://lists.01.org/mailman/listinfo/linux-nvdimm
 
-1332234afc3b756a4a70a75a27737ba3150be699db1dd71da2b859f75721da94
+d20625ef700ddd1457a62b199e92eb6f01ac855a065535b7dcc67cf1e4d06f3b
