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

diff --git a/a/1.txt b/N1/1.txt
index 8e932c2..e572a39 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,24 +1,30 @@
-T24gU3VuLCAyMDE2LTA1LTA4IGF0IDAyOjAxIC0wNzAwLCBoY2hAaW5mcmFkZWFkLm9yZyB3cm90
-ZToNCj4gT24gVGh1LCBNYXkgMDUsIDIwMTYgYXQgMDk6NDU6MDdQTSArMDAwMCwgVmVybWEsIFZp
-c2hhbCBMIHdyb3RlOg0KPiA+IA0KPiA+IEknbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJz
-dGFuZCBob3cgdGhpcyB3aWxsIHdvcms/IENhbiB5b3UNCj4gPiBleHBsYWluDQo+ID4gYSBiaXQ/
-IFdvdWxkIHdlIGhhdmUgdG8gZXhwb3J0IHJ3X2J5dGVzIHVwIHRvIGxheWVycyBhYm92ZSB0aGUg
-cG1lbQ0KPiA+IGRyaXZlcj8gV2hlcmUgZG9lcyBnZXRfdXNlcl9wYWdlcyBjb21lIGluPw0KPiBB
-IERBWCBmaWxlc3lzdGVtIGNhbiBkaXJlY3RseSB1c2UgdGhlIG52ZGltbSBsYXllciB0aGUgc2Ft
-ZSB3YXkgYnR0DQo+IGRvZSxzIHdoYXQncyB0aGUgcHJvYmxlbT8NCg0KVGhlIEJUVCBkb2VzIHJ3
-X2J5dGVzIHRocm91Z2ggYW4gaW50ZXJuYWwtdG8tbGlibnZkaW1tIG1lY2hhbmlzbSwgYnV0DQpy
-d19ieXRlcyBpc24ndCBleHBvcnRlZCB0byB0aGUgZmlsZXN5c3RlbSwgY3VycmVudGx5Li4gVG8g
-ZG8gdGhpcyB3ZSdkDQpoYXZlIHRvIGVpdGhlciBhZGQgYW4gcndfYnl0ZXMgdG8gYmxvY2sgZGV2
-aWNlIG9wZXJhdGlvbnMuLi5vcg0Kc29tZXRoaW5nLg0KDQpBbm90aGVyIHRoaW5nIGlzIHJ3X2J5
-dGVzIGN1cnJlbnRseSBkb2Vzbid0IGRvIGVycm9yIGNsZWFyaW5nIGVpdGhlci4NCldlIHN0b3Jl
-IGJhZGJsb2NrcyBhdCBzZWN0b3IgZ3JhbnVsYXJpdHksIGFuZCBsaWtlIERhbiBzYWlkIGVhcmxp
-ZXIsDQp0aGF0IGhpZGVzIHRoZSBjbGVhcl9lcnJvciBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzIGFu
-ZCB1cHBlciBsYXllcnMNCmRvbid0IGhhdmUgdG8gYmUgYXdhcmUgb2YgaXQuIFRvIG1ha2Ugcndf
-Ynl0ZXMgY2xlYXIgc3ViLXNlY3RvciBlcnJvcnMsDQp3ZSdkIGhhdmUgdG8gY2hhbmdlIHRoZSBn
-cmFudWxhcml0eSBvZiBiYWQtYmxvY2tzLCBhbmQgbWFrZSB1cHBlcg0KbGF5ZXJzIGF3YXJlIG9m
-IHRoZSBjbGVhcmluZyBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzLg0KDQpVc2luZyBhIGJsb2NrLXdy
-aXRlIHNlbWFudGljIGZvciBjbGVhcmluZyBoaWRlcyBhbGwgdGhpcyBhd2F5Lg0KDQo+IA0KPiBS
-ZSBnZXRfdXNlcl9wYWdlcyBteSBpZGVhIHdhcyB0byBzaW1wbHkgdXNlIHRoYXQgdG8gbG9jayBk
-b3duIHRoZQ0KPiB1c2VyDQo+IHBhZ2VzIHNvIHRoYXQgd2UgY2FuIGNhbGwgcndfYnl0ZXMgb24g
-aXQuwqDCoEhvdyBlbHNlIHdvdWxkIHlvdSBkbw0KPiBpdD/CoMKgRG8NCj4gYSBrbWFsbG9jLCBj
-b3B5X2Zyb21fdXNlciBhbmQgdGhlbiBhbm90aGVyIG1lbWNweT8=
+On Sun, 2016-05-08 at 02:01 -0700, hch@infradead.org wrote:
+> On Thu, May 05, 2016 at 09:45:07PM +0000, Verma, Vishal L wrote:
+> > 
+> > 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?
+> A DAX filesystem can directly use the nvdimm layer the same way btt
+> doe,s what's the problem?
+
+The BTT does rw_bytes through an internal-to-libnvdimm mechanism, but
+rw_bytes isn't exported to the filesystem, currently.. To do this we'd
+have to either add an rw_bytes to block device operations...or
+something.
+
+Another thing is rw_bytes currently doesn't do error clearing either.
+We store badblocks at sector granularity, and like Dan said earlier,
+that hides the clear_error alignment requirements and upper layers
+don't have to be aware of it. To make rw_bytes clear sub-sector errors,
+we'd have to change the granularity of bad-blocks, and make upper
+layers aware of the clearing alignment requirements.
+
+Using a block-write semantic for clearing hides all this away.
+
+> 
+> Re get_user_pages my idea was to simply use that to lock down the
+> user
+> pages so that we can call rw_bytes on it.  How else would you do
+> it?  Do
+> a kmalloc, copy_from_user and then another memcpy?
diff --git a/a/content_digest b/N1/content_digest
index 39de575..95f44f7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -27,29 +27,35 @@
  " matthew@wil.cx <matthew@wil.cx>\0"
  "\00:1\0"
  "b\0"
- "T24gU3VuLCAyMDE2LTA1LTA4IGF0IDAyOjAxIC0wNzAwLCBoY2hAaW5mcmFkZWFkLm9yZyB3cm90\n"
- "ZToNCj4gT24gVGh1LCBNYXkgMDUsIDIwMTYgYXQgMDk6NDU6MDdQTSArMDAwMCwgVmVybWEsIFZp\n"
- "c2hhbCBMIHdyb3RlOg0KPiA+IA0KPiA+IEknbSBub3Qgc3VyZSBJIGNvbXBsZXRlbHkgdW5kZXJz\n"
- "dGFuZCBob3cgdGhpcyB3aWxsIHdvcms/IENhbiB5b3UNCj4gPiBleHBsYWluDQo+ID4gYSBiaXQ/\n"
- "IFdvdWxkIHdlIGhhdmUgdG8gZXhwb3J0IHJ3X2J5dGVzIHVwIHRvIGxheWVycyBhYm92ZSB0aGUg\n"
- "cG1lbQ0KPiA+IGRyaXZlcj8gV2hlcmUgZG9lcyBnZXRfdXNlcl9wYWdlcyBjb21lIGluPw0KPiBB\n"
- "IERBWCBmaWxlc3lzdGVtIGNhbiBkaXJlY3RseSB1c2UgdGhlIG52ZGltbSBsYXllciB0aGUgc2Ft\n"
- "ZSB3YXkgYnR0DQo+IGRvZSxzIHdoYXQncyB0aGUgcHJvYmxlbT8NCg0KVGhlIEJUVCBkb2VzIHJ3\n"
- "X2J5dGVzIHRocm91Z2ggYW4gaW50ZXJuYWwtdG8tbGlibnZkaW1tIG1lY2hhbmlzbSwgYnV0DQpy\n"
- "d19ieXRlcyBpc24ndCBleHBvcnRlZCB0byB0aGUgZmlsZXN5c3RlbSwgY3VycmVudGx5Li4gVG8g\n"
- "ZG8gdGhpcyB3ZSdkDQpoYXZlIHRvIGVpdGhlciBhZGQgYW4gcndfYnl0ZXMgdG8gYmxvY2sgZGV2\n"
- "aWNlIG9wZXJhdGlvbnMuLi5vcg0Kc29tZXRoaW5nLg0KDQpBbm90aGVyIHRoaW5nIGlzIHJ3X2J5\n"
- "dGVzIGN1cnJlbnRseSBkb2Vzbid0IGRvIGVycm9yIGNsZWFyaW5nIGVpdGhlci4NCldlIHN0b3Jl\n"
- "IGJhZGJsb2NrcyBhdCBzZWN0b3IgZ3JhbnVsYXJpdHksIGFuZCBsaWtlIERhbiBzYWlkIGVhcmxp\n"
- "ZXIsDQp0aGF0IGhpZGVzIHRoZSBjbGVhcl9lcnJvciBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzIGFu\n"
- "ZCB1cHBlciBsYXllcnMNCmRvbid0IGhhdmUgdG8gYmUgYXdhcmUgb2YgaXQuIFRvIG1ha2Ugcndf\n"
- "Ynl0ZXMgY2xlYXIgc3ViLXNlY3RvciBlcnJvcnMsDQp3ZSdkIGhhdmUgdG8gY2hhbmdlIHRoZSBn\n"
- "cmFudWxhcml0eSBvZiBiYWQtYmxvY2tzLCBhbmQgbWFrZSB1cHBlcg0KbGF5ZXJzIGF3YXJlIG9m\n"
- "IHRoZSBjbGVhcmluZyBhbGlnbm1lbnQgcmVxdWlyZW1lbnRzLg0KDQpVc2luZyBhIGJsb2NrLXdy\n"
- "aXRlIHNlbWFudGljIGZvciBjbGVhcmluZyBoaWRlcyBhbGwgdGhpcyBhd2F5Lg0KDQo+IA0KPiBS\n"
- "ZSBnZXRfdXNlcl9wYWdlcyBteSBpZGVhIHdhcyB0byBzaW1wbHkgdXNlIHRoYXQgdG8gbG9jayBk\n"
- "b3duIHRoZQ0KPiB1c2VyDQo+IHBhZ2VzIHNvIHRoYXQgd2UgY2FuIGNhbGwgcndfYnl0ZXMgb24g\n"
- "aXQuwqDCoEhvdyBlbHNlIHdvdWxkIHlvdSBkbw0KPiBpdD/CoMKgRG8NCj4gYSBrbWFsbG9jLCBj\n"
- b3B5X2Zyb21fdXNlciBhbmQgdGhlbiBhbm90aGVyIG1lbWNweT8=
+ "On Sun, 2016-05-08 at 02:01 -0700, hch@infradead.org wrote:\n"
+ "> On Thu, May 05, 2016 at 09:45:07PM +0000, Verma, Vishal L wrote:\n"
+ "> > \n"
+ "> > I'm not sure I completely understand how this will work? Can you\n"
+ "> > 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"
+ "> A DAX filesystem can directly use the nvdimm layer the same way btt\n"
+ "> doe,s what's the problem?\n"
+ "\n"
+ "The BTT does rw_bytes through an internal-to-libnvdimm mechanism, but\n"
+ "rw_bytes isn't exported to the filesystem, currently.. To do this we'd\n"
+ "have to either add an rw_bytes to block device operations...or\n"
+ "something.\n"
+ "\n"
+ "Another thing is rw_bytes currently doesn't do error clearing either.\n"
+ "We store badblocks at sector granularity, and like Dan said earlier,\n"
+ "that hides the clear_error alignment requirements and upper layers\n"
+ "don't have to be aware of it. To make rw_bytes clear sub-sector errors,\n"
+ "we'd have to change the granularity of bad-blocks, and make upper\n"
+ "layers aware of the clearing alignment requirements.\n"
+ "\n"
+ "Using a block-write semantic for clearing hides all this away.\n"
+ "\n"
+ "> \n"
+ "> Re get_user_pages my idea was to simply use that to lock down the\n"
+ "> user\n"
+ "> pages so that we can call rw_bytes on it.\302\240\302\240How else would you do\n"
+ "> it?\302\240\302\240Do\n"
+ > a kmalloc, copy_from_user and then another memcpy?
 
-8bbdbd487bd768ef34fa7c82f4b4982f23d8f76b215bb540554865b57d72bb37
+cb6658801814aa16b8a3efafc61fd23e5288642347e45ae441cffaf225d5513b
