All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20160502230422.GQ26977@dastard>

diff --git a/a/1.txt b/N1/1.txt
index e79f960..35beaec 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -226,8 +226,7 @@ Dave.
 Dave Chinner
 david@fromorbit.com
 
---
-To unsubscribe, send a message with 'unsubscribe linux-mm' in
-the body to majordomo@kvack.org.  For more info on Linux MM,
-see: http://www.linux-mm.org/ .
-Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
+_______________________________________________
+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 a4281e9..4045528 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -12,23 +12,23 @@
  "Subject\0Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io\0"
  "Date\0Tue, 3 May 2016 09:04:22 +1000\0"
  "To\0Jeff Moyer <jmoyer@redhat.com>\0"
- "Cc\0Dan J. Williams <dan.j.williams@intel.com>"
+ "Cc\0hch@infradead.org <hch@infradead.org>"
+  jack@suse.cz <jack@suse.cz>
+  axboe@fb.com <axboe@fb.com>
   Verma
   Vishal L <vishal.l.verma@intel.com>
   linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
-  hch@infradead.org <hch@infradead.org>
   xfs@oss.sgi.com <xfs@oss.sgi.com>
-  linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
+  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>
-  axboe@fb.com <axboe@fb.com>
-  akpm@linux-foundation.org <akpm@linux-foundation.org>
+  linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
   linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
+  Dan J. Williams <dan.j.williams@intel.com>
   linux-ext4@vger.kernel.org <linux-ext4@vger.kernel.org>
+  akpm@linux-foundation.org <akpm@linux-foundation.org>
   Wilcox
-  Matthew R <matthew.r.wilcox@intel.com>
- " jack@suse.cz <jack@suse.cz>\0"
+ " Matthew R <matthew.r.wilcox@intel.com>\0"
  "\00:1\0"
  "b\0"
  "On Mon, May 02, 2016 at 11:18:36AM -0400, Jeff Moyer wrote:\n"
@@ -259,10 +259,9 @@
  "Dave Chinner\n"
  "david@fromorbit.com\n"
  "\n"
- "--\n"
- "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
- "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
- "see: http://www.linux-mm.org/ .\n"
- "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
+ "_______________________________________________\n"
+ "xfs mailing list\n"
+ "xfs@oss.sgi.com\n"
+ http://oss.sgi.com/mailman/listinfo/xfs
 
-e37f357728049e59ca275c3971b74b7f442f1218daf4038bbc5fe56b861b32b5
+607fba0fe3a981456d7b9b523d797856c1a52fa2f5449386f33bbefc32c017f8

diff --git a/a/1.txt b/N2/1.txt
index e79f960..8b593df 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -102,10 +102,10 @@ of trucks in it, not handwaving...
 
 > >> To summarize, the two cases we want to handle are:
 > >> 1. Application has inbuilt recovery:
-> >>   - hits badblock
-> >>   - figures out it is able to recover the data
-> >>   - handles SIGBUS or EIO
-> >>   - does a (sector aligned) write() to restore the data
+> >> � - hits badblock
+> >> � - figures out it is able to recover the data
+> >> � - handles SIGBUS or EIO
+> >> � - does a (sector aligned) write() to restore the data
 > >
 > > The "figures out" step here is where >95% of the work we'd have to
 > > do is. And that's in filesystem and block layer code, not
@@ -173,9 +173,9 @@ LBA range....
 
 
 > >> 2. Application doesn't have any inbuilt recovery mechanism
-> >>   - hits badblock
-> >>   - gets SIGBUS (or EIO) and crashes
-> >>   - Sysadmin restores file from backup
+> >> � - hits badblock
+> >> � - gets SIGBUS (or EIO) and crashes
+> >> � - Sysadmin restores file from backup
 > >
 > > Which is no different to an existing non-DAX application getting an
 > > EIO/sigbus from current storage technologies.
diff --git a/a/content_digest b/N2/content_digest
index a4281e9..ea0f9a3 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -135,10 +135,10 @@
  "\n"
  "> >> To summarize, the two cases we want to handle are:\n"
  "> >> 1. Application has inbuilt recovery:\n"
- "> >> \302\240 - hits badblock\n"
- "> >> \302\240 - figures out it is able to recover the data\n"
- "> >> \302\240 - handles SIGBUS or EIO\n"
- "> >> \302\240 - does a (sector aligned) write() to restore the data\n"
+ "> >> \303\257\302\277\302\275 - hits badblock\n"
+ "> >> \303\257\302\277\302\275 - figures out it is able to recover the data\n"
+ "> >> \303\257\302\277\302\275 - handles SIGBUS or EIO\n"
+ "> >> \303\257\302\277\302\275 - does a (sector aligned) write() to restore the data\n"
  "> >\n"
  "> > The \"figures out\" step here is where >95% of the work we'd have to\n"
  "> > do is. And that's in filesystem and block layer code, not\n"
@@ -206,9 +206,9 @@
  "\n"
  "\n"
  "> >> 2. Application doesn't have any inbuilt recovery mechanism\n"
- "> >> \302\240 - hits badblock\n"
- "> >> \302\240 - gets SIGBUS (or EIO) and crashes\n"
- "> >> \302\240 - Sysadmin restores file from backup\n"
+ "> >> \303\257\302\277\302\275 - hits badblock\n"
+ "> >> \303\257\302\277\302\275 - gets SIGBUS (or EIO) and crashes\n"
+ "> >> \303\257\302\277\302\275 - Sysadmin restores file from backup\n"
  "> >\n"
  "> > Which is no different to an existing non-DAX application getting an\n"
  "> > EIO/sigbus from current storage technologies.\n"
@@ -265,4 +265,4 @@
  "see: http://www.linux-mm.org/ .\n"
  "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-e37f357728049e59ca275c3971b74b7f442f1218daf4038bbc5fe56b861b32b5
+78e9a9ef6789bc8d1ca2e3c57a88b2da31360fb75248c5e31dfa4afc009e7515

diff --git a/a/1.txt b/N3/1.txt
index e79f960..c975daf 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -102,10 +102,10 @@ of trucks in it, not handwaving...
 
 > >> To summarize, the two cases we want to handle are:
 > >> 1. Application has inbuilt recovery:
-> >>   - hits badblock
-> >>   - figures out it is able to recover the data
-> >>   - handles SIGBUS or EIO
-> >>   - does a (sector aligned) write() to restore the data
+> >>   - hits badblock
+> >>   - figures out it is able to recover the data
+> >>   - handles SIGBUS or EIO
+> >>   - does a (sector aligned) write() to restore the data
 > >
 > > The "figures out" step here is where >95% of the work we'd have to
 > > do is. And that's in filesystem and block layer code, not
@@ -173,9 +173,9 @@ LBA range....
 
 
 > >> 2. Application doesn't have any inbuilt recovery mechanism
-> >>   - hits badblock
-> >>   - gets SIGBUS (or EIO) and crashes
-> >>   - Sysadmin restores file from backup
+> >>   - hits badblock
+> >>   - gets SIGBUS (or EIO) and crashes
+> >>   - Sysadmin restores file from backup
 > >
 > > Which is no different to an existing non-DAX application getting an
 > > EIO/sigbus from current storage technologies.
diff --git a/a/content_digest b/N3/content_digest
index a4281e9..9565b7e 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -135,10 +135,10 @@
  "\n"
  "> >> To summarize, the two cases we want to handle are:\n"
  "> >> 1. Application has inbuilt recovery:\n"
- "> >> \302\240 - hits badblock\n"
- "> >> \302\240 - figures out it is able to recover the data\n"
- "> >> \302\240 - handles SIGBUS or EIO\n"
- "> >> \302\240 - does a (sector aligned) write() to restore the data\n"
+ "> >>   - hits badblock\n"
+ "> >>   - figures out it is able to recover the data\n"
+ "> >>   - handles SIGBUS or EIO\n"
+ "> >>   - does a (sector aligned) write() to restore the data\n"
  "> >\n"
  "> > The \"figures out\" step here is where >95% of the work we'd have to\n"
  "> > do is. And that's in filesystem and block layer code, not\n"
@@ -206,9 +206,9 @@
  "\n"
  "\n"
  "> >> 2. Application doesn't have any inbuilt recovery mechanism\n"
- "> >> \302\240 - hits badblock\n"
- "> >> \302\240 - gets SIGBUS (or EIO) and crashes\n"
- "> >> \302\240 - Sysadmin restores file from backup\n"
+ "> >>   - hits badblock\n"
+ "> >>   - gets SIGBUS (or EIO) and crashes\n"
+ "> >>   - Sysadmin restores file from backup\n"
  "> >\n"
  "> > Which is no different to an existing non-DAX application getting an\n"
  "> > EIO/sigbus from current storage technologies.\n"
@@ -265,4 +265,4 @@
  "see: http://www.linux-mm.org/ .\n"
  "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
 
-e37f357728049e59ca275c3971b74b7f442f1218daf4038bbc5fe56b861b32b5
+f7145c948de3df7bd8b0930a6000232a49dd12d9201e7e219dd8d93f5817afb1

diff --git a/a/1.txt b/N4/1.txt
index e79f960..4b173b2 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -225,9 +225,3 @@ Dave.
 -- 
 Dave Chinner
 david@fromorbit.com
-
---
-To unsubscribe, send a message with 'unsubscribe linux-mm' in
-the body to majordomo@kvack.org.  For more info on Linux MM,
-see: http://www.linux-mm.org/ .
-Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
diff --git a/a/content_digest b/N4/content_digest
index a4281e9..8657b37 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -257,12 +257,6 @@
  "Dave.\n"
  "-- \n"
  "Dave Chinner\n"
- "david@fromorbit.com\n"
- "\n"
- "--\n"
- "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n"
- "the body to majordomo@kvack.org.  For more info on Linux MM,\n"
- "see: http://www.linux-mm.org/ .\n"
- "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>"
+ david@fromorbit.com
 
-e37f357728049e59ca275c3971b74b7f442f1218daf4038bbc5fe56b861b32b5
+705e698a8ba57e63b7e36ef62c6e28480005ca20cc937f8a1dbfe490c3d1f4f8

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.