All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20160509145527.GA31079@linux.intel.com>

diff --git a/a/1.txt b/N1/1.txt
index fc53f89..9e1a2d1 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,16 +4,16 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > > > 
 > > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > 
-> > > dax_clear_sectors() cannot handle poisoned blocks.��These must be
-> > > zeroed using the BIO interface instead.��Convert ext2 and XFS to
+> > > dax_clear_sectors() cannot handle poisoned blocks.  These must be
+> > > zeroed using the BIO interface instead.  Convert ext2 and XFS to
 > > > use
 > > > only sb_issue_zerout().
 > > > 
 > > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > [vishal: Also remove the dax_clear_sectors function entirely]
 > > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
-> > Just to make sure:��the existing sb_issue_zerout as in 4.6-rc
-> > is already doing the right thing for DAX?��I've got a pending
+> > Just to make sure:  the existing sb_issue_zerout as in 4.6-rc
+> > is already doing the right thing for DAX?  I've got a pending
 > > patchset
 > > for XFS that introduces another dax_clear_sectors users, but if it's
 > > already safe to use blkdev_issue_zeroout I can switch to that and
@@ -22,10 +22,15 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > 
 > I believe so - Jan has moved all unwritten extent conversions out of
 > DAX with his patch set, and I believe zeroing through the driver is
-> always fine. Ross or Jan could confirm though.�
+> always fine. Ross or Jan could confirm though. 
 
 Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the
 right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()
 => __blkdev_issue_zeroout() because we don't have support for discard or
 write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which
 will do the zeroing as normal writes.
+
+_______________________________________________
+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 68d1b23..7880ee5 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -7,25 +7,24 @@
  "Date\0Mon, 9 May 2016 08:55:27 -0600\0"
  "To\0Verma"
  " Vishal L <vishal.l.verma@intel.com>\0"
- "Cc\0hch@infradead.org <hch@infradead.org>"
+ "Cc\0linux-block@vger.kernel.org <linux-block@vger.kernel.org>"
+  jack@suse.cz <jack@suse.cz>
+  boaz@plexistor.com <boaz@plexistor.com>
+  axboe@fb.com <axboe@fb.com>
+  linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
   linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
-  linux-block@vger.kernel.org <linux-block@vger.kernel.org>
   xfs@oss.sgi.com <xfs@oss.sgi.com>
-  linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org>
-  jmoyer@redhat.com <jmoyer@redhat.com>
+  hch@infradead.org <hch@infradead.org>
   linux-mm@kvack.org <linux-mm@kvack.org>
+  jmoyer@redhat.com <jmoyer@redhat.com>
+  Wilcox
+  Matthew R <matthew.r.wilcox@intel.com>
+  ross.zwisler@linux.intel.com <ross.zwisler@linux.intel.com>
+  linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
   Williams
   Dan J <dan.j.williams@intel.com>
-  axboe@fb.com <axboe@fb.com>
-  akpm@linux-foundation.org <akpm@linux-foundation.org>
-  linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>
-  ross.zwisler@linux.intel.com <ross.zwisler@linux.intel.com>
   linux-ext4@vger.kernel.org <linux-ext4@vger.kernel.org>
-  boaz@plexistor.com <boaz@plexistor.com>
-  Wilcox
-  Matthew R <matthew.r.wilcox@intel.com>
-  david@fromorbit.com <david@fromorbit.com>
- " jack@suse.cz <jack@suse.cz>\0"
+ " akpm@linux-foundation.org <akpm@linux-foundation.org>\0"
  "\00:1\0"
  "b\0"
  "On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:\n"
@@ -34,16 +33,16 @@
  "> > > \n"
  "> > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > \n"
- "> > > dax_clear_sectors() cannot handle poisoned blocks.\303\257\302\277\302\275\303\257\302\277\302\275These must be\n"
- "> > > zeroed using the BIO interface instead.\303\257\302\277\302\275\303\257\302\277\302\275Convert ext2 and XFS to\n"
+ "> > > dax_clear_sectors() cannot handle poisoned blocks.\302\240\302\240These must be\n"
+ "> > > zeroed using the BIO interface instead.\302\240\302\240Convert ext2 and XFS to\n"
  "> > > use\n"
  "> > > only sb_issue_zerout().\n"
  "> > > \n"
  "> > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > [vishal: Also remove the dax_clear_sectors function entirely]\n"
  "> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>\n"
- "> > Just to make sure:\303\257\302\277\302\275\303\257\302\277\302\275the existing sb_issue_zerout as in 4.6-rc\n"
- "> > is already doing the right thing for DAX?\303\257\302\277\302\275\303\257\302\277\302\275I've got a pending\n"
+ "> > Just to make sure:\302\240\302\240the existing sb_issue_zerout as in 4.6-rc\n"
+ "> > is already doing the right thing for DAX?\302\240\302\240I've got a pending\n"
  "> > patchset\n"
  "> > for XFS that introduces another dax_clear_sectors users, but if it's\n"
  "> > already safe to use blkdev_issue_zeroout I can switch to that and\n"
@@ -52,12 +51,17 @@
  "> \n"
  "> I believe so - Jan has moved all unwritten extent conversions out of\n"
  "> DAX with his patch set, and I believe zeroing through the driver is\n"
- "> always fine. Ross or Jan could confirm though.\303\257\302\277\302\275\n"
+ "> always fine. Ross or Jan could confirm though.\302\240\n"
  "\n"
  "Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the\n"
  "right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()\n"
  "=> __blkdev_issue_zeroout() because we don't have support for discard or\n"
  "write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which\n"
- will do the zeroing as normal writes.
+ "will do the zeroing as normal writes.\n"
+ "\n"
+ "_______________________________________________\n"
+ "xfs mailing list\n"
+ "xfs@oss.sgi.com\n"
+ http://oss.sgi.com/mailman/listinfo/xfs
 
-449235f5ef4bd45451a48edcd854230821492bf82cf11278dea8b6f04828ded4
+fcb073077dd5bffd76820be400dd0c219ce0d778474142729a21ec3e4efacc82

diff --git a/a/1.txt b/N2/1.txt
index fc53f89..0b28a31 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -29,3 +29,9 @@ right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()
 => __blkdev_issue_zeroout() because we don't have support for discard or
 write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which
 will do the zeroing as normal writes.
+
+--
+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/N2/content_digest
index 68d1b23..e653605 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -58,6 +58,12 @@
  "right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()\n"
  "=> __blkdev_issue_zeroout() because we don't have support for discard or\n"
  "write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which\n"
- will do the zeroing as normal writes.
+ "will do the zeroing as normal writes.\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>"
 
-449235f5ef4bd45451a48edcd854230821492bf82cf11278dea8b6f04828ded4
+9ea7ff7f89501398886552a38f2663fc240761e7f3ebb76d76eefe66911e7388

diff --git a/a/1.txt b/N3/1.txt
index fc53f89..3a863b2 100644
--- a/a/1.txt
+++ b/N3/1.txt
@@ -4,16 +4,16 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > > > 
 > > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > 
-> > > dax_clear_sectors() cannot handle poisoned blocks.��These must be
-> > > zeroed using the BIO interface instead.��Convert ext2 and XFS to
+> > > dax_clear_sectors() cannot handle poisoned blocks.  These must be
+> > > zeroed using the BIO interface instead.  Convert ext2 and XFS to
 > > > use
 > > > only sb_issue_zerout().
 > > > 
 > > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > [vishal: Also remove the dax_clear_sectors function entirely]
 > > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
-> > Just to make sure:��the existing sb_issue_zerout as in 4.6-rc
-> > is already doing the right thing for DAX?��I've got a pending
+> > Just to make sure:  the existing sb_issue_zerout as in 4.6-rc
+> > is already doing the right thing for DAX?  I've got a pending
 > > patchset
 > > for XFS that introduces another dax_clear_sectors users, but if it's
 > > already safe to use blkdev_issue_zeroout I can switch to that and
@@ -22,10 +22,16 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > 
 > I believe so - Jan has moved all unwritten extent conversions out of
 > DAX with his patch set, and I believe zeroing through the driver is
-> always fine. Ross or Jan could confirm though.�
+> always fine. Ross or Jan could confirm though. 
 
 Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the
 right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()
 => __blkdev_issue_zeroout() because we don't have support for discard or
 write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which
 will do the zeroing as normal writes.
+
+--
+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/N3/content_digest
index 68d1b23..ca281d6 100644
--- a/a/content_digest
+++ b/N3/content_digest
@@ -34,16 +34,16 @@
  "> > > \n"
  "> > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > \n"
- "> > > dax_clear_sectors() cannot handle poisoned blocks.\303\257\302\277\302\275\303\257\302\277\302\275These must be\n"
- "> > > zeroed using the BIO interface instead.\303\257\302\277\302\275\303\257\302\277\302\275Convert ext2 and XFS to\n"
+ "> > > dax_clear_sectors() cannot handle poisoned blocks.  These must be\n"
+ "> > > zeroed using the BIO interface instead.  Convert ext2 and XFS to\n"
  "> > > use\n"
  "> > > only sb_issue_zerout().\n"
  "> > > \n"
  "> > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > [vishal: Also remove the dax_clear_sectors function entirely]\n"
  "> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>\n"
- "> > Just to make sure:\303\257\302\277\302\275\303\257\302\277\302\275the existing sb_issue_zerout as in 4.6-rc\n"
- "> > is already doing the right thing for DAX?\303\257\302\277\302\275\303\257\302\277\302\275I've got a pending\n"
+ "> > Just to make sure:  the existing sb_issue_zerout as in 4.6-rc\n"
+ "> > is already doing the right thing for DAX?  I've got a pending\n"
  "> > patchset\n"
  "> > for XFS that introduces another dax_clear_sectors users, but if it's\n"
  "> > already safe to use blkdev_issue_zeroout I can switch to that and\n"
@@ -52,12 +52,18 @@
  "> \n"
  "> I believe so - Jan has moved all unwritten extent conversions out of\n"
  "> DAX with his patch set, and I believe zeroing through the driver is\n"
- "> always fine. Ross or Jan could confirm though.\303\257\302\277\302\275\n"
+ "> always fine. Ross or Jan could confirm though. \n"
  "\n"
  "Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the\n"
  "right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()\n"
  "=> __blkdev_issue_zeroout() because we don't have support for discard or\n"
  "write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which\n"
- will do the zeroing as normal writes.
+ "will do the zeroing as normal writes.\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>"
 
-449235f5ef4bd45451a48edcd854230821492bf82cf11278dea8b6f04828ded4
+1b56cf86b025af8dc7b58dd65fa526c52aec820ca4a41475375121f1f9bafa14

diff --git a/a/1.txt b/N4/1.txt
index fc53f89..2039ae8 100644
--- a/a/1.txt
+++ b/N4/1.txt
@@ -4,16 +4,16 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > > > 
 > > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > 
-> > > dax_clear_sectors() cannot handle poisoned blocks.��These must be
-> > > zeroed using the BIO interface instead.��Convert ext2 and XFS to
+> > > dax_clear_sectors() cannot handle poisoned blocks.  These must be
+> > > zeroed using the BIO interface instead.  Convert ext2 and XFS to
 > > > use
 > > > only sb_issue_zerout().
 > > > 
 > > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
 > > > [vishal: Also remove the dax_clear_sectors function entirely]
 > > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
-> > Just to make sure:��the existing sb_issue_zerout as in 4.6-rc
-> > is already doing the right thing for DAX?��I've got a pending
+> > Just to make sure:  the existing sb_issue_zerout as in 4.6-rc
+> > is already doing the right thing for DAX?  I've got a pending
 > > patchset
 > > for XFS that introduces another dax_clear_sectors users, but if it's
 > > already safe to use blkdev_issue_zeroout I can switch to that and
@@ -22,7 +22,7 @@ On Sun, May 08, 2016 at 06:46:13PM +0000, Verma, Vishal L wrote:
 > 
 > I believe so - Jan has moved all unwritten extent conversions out of
 > DAX with his patch set, and I believe zeroing through the driver is
-> always fine. Ross or Jan could confirm though.�
+> always fine. Ross or Jan could confirm though. 
 
 Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the
 right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()
diff --git a/a/content_digest b/N4/content_digest
index 68d1b23..0c43453 100644
--- a/a/content_digest
+++ b/N4/content_digest
@@ -34,16 +34,16 @@
  "> > > \n"
  "> > > From: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > \n"
- "> > > dax_clear_sectors() cannot handle poisoned blocks.\303\257\302\277\302\275\303\257\302\277\302\275These must be\n"
- "> > > zeroed using the BIO interface instead.\303\257\302\277\302\275\303\257\302\277\302\275Convert ext2 and XFS to\n"
+ "> > > dax_clear_sectors() cannot handle poisoned blocks.\302\240\302\240These must be\n"
+ "> > > zeroed using the BIO interface instead.\302\240\302\240Convert ext2 and XFS to\n"
  "> > > use\n"
  "> > > only sb_issue_zerout().\n"
  "> > > \n"
  "> > > Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>\n"
  "> > > [vishal: Also remove the dax_clear_sectors function entirely]\n"
  "> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>\n"
- "> > Just to make sure:\303\257\302\277\302\275\303\257\302\277\302\275the existing sb_issue_zerout as in 4.6-rc\n"
- "> > is already doing the right thing for DAX?\303\257\302\277\302\275\303\257\302\277\302\275I've got a pending\n"
+ "> > Just to make sure:\302\240\302\240the existing sb_issue_zerout as in 4.6-rc\n"
+ "> > is already doing the right thing for DAX?\302\240\302\240I've got a pending\n"
  "> > patchset\n"
  "> > for XFS that introduces another dax_clear_sectors users, but if it's\n"
  "> > already safe to use blkdev_issue_zeroout I can switch to that and\n"
@@ -52,7 +52,7 @@
  "> \n"
  "> I believe so - Jan has moved all unwritten extent conversions out of\n"
  "> DAX with his patch set, and I believe zeroing through the driver is\n"
- "> always fine. Ross or Jan could confirm though.\303\257\302\277\302\275\n"
+ "> always fine. Ross or Jan could confirm though.\302\240\n"
  "\n"
  "Yep, I believe that the existing sb_issue_zeroout() as of v4.6-rc* does the\n"
  "right thing.  We'll end up calling sb_issue_zeroout() => blkdev_issue_zeroout()\n"
@@ -60,4 +60,4 @@
  "write_same in PMEM.  This will send zero page BIOs to the PMEM driver, which\n"
  will do the zeroing as normal writes.
 
-449235f5ef4bd45451a48edcd854230821492bf82cf11278dea8b6f04828ded4
+84b456eced2fb6d13ff7fe2cdcd8128d23c5dacbcc86efcf0e92a90aa6961d45

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.