All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1291754340-sup-1631@think>

diff --git a/a/1.txt b/N1/1.txt
index e51d352..440a42c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,36 +1,48 @@
 Excerpts from Jon Nelson's message of 2010-12-07 15:25:47 -0500:
-> On Tue, Dec 7, 2010 at 2:02 PM, Chris Mason <chris.mason@oracle.com> wrote:
+> On Tue, Dec 7, 2010 at 2:02 PM, Chris Mason <chris.mason@oracle.com> =
+wrote:
 > > Excerpts from Jon Nelson's message of 2010-12-07 14:34:40 -0500:
-> >> On Tue, Dec 7, 2010 at 12:52 PM, Chris Mason <chris.mason@oracle.com> wrote:
-> >> >> postgresql errors. Typically, header corruption but from the limited
-> >> >> visibility I've had into this via strace, what I see is zeroed pages
+> >> On Tue, Dec 7, 2010 at 12:52 PM, Chris Mason <chris.mason@oracle.c=
+om> wrote:
+> >> >> postgresql errors. Typically, header corruption but from the li=
+mited
+> >> >> visibility I've had into this via strace, what I see is zeroed =
+pages
 > >> >> where there shouldn't be.
 > >> >
-> >> > This sounds a lot like a bug higher up than dm-crypt.  Zeros tend to
-> >> > come from some piece of code explicitly filling a page with zeros, and
-> >> > that often happens in the corner cases for O_DIRECT and a few other
+> >> > This sounds a lot like a bug higher up than dm-crypt. =C2=A0Zero=
+s tend to
+> >> > come from some piece of code explicitly filling a page with zero=
+s, and
+> >> > that often happens in the corner cases for O_DIRECT and a few ot=
+her
 > >> > places in the filesystem.
 > >> >
 > >> > Have you tried triggering this with a regular block device?
 > >>
-> >> I just tried the whole set of tests, but with /dev/sdb directly (as
+> >> I just tried the whole set of tests, but with /dev/sdb directly (a=
+s
 > >> ext4) without any crypt-y bits.
-> >> It takes more iterations but out of 6 tests I had one failure: same
+> >> It takes more iterations but out of 6 tests I had one failure: sam=
+e
 > >> type of thing, 'invalid page header in block ....'.
 > >>
-> >> I can't guarantee that it is a full-page of zeroes, just what I saw
+> >> I can't guarantee that it is a full-page of zeroes, just what I sa=
+w
 > >> from the (limited) stracing I did.
 > >
 > > Fantastic. Now for our usual suspects:
 > >
-> > 1) Is postgres using O_DIRECT?  If yes, please turn it off
-> 
+> > 1) Is postgres using O_DIRECT? =C2=A0If yes, please turn it off
+>=20
 > According to strace, O_DIRECT didn't show up once during the test.
-> 
-> > 2) Is postgres allocating sparse files?  If yes, please have it fully
+>=20
+> > 2) Is postgres allocating sparse files? =C2=A0If yes, please have i=
+t fully
 > > allocate the file instead.
-> 
-> That's a tough one. I don't think postgresql does that, but I'm not an
+>=20
+> That's a tough one. I don't think postgresql does that, but I'm not a=
+n
 > expert here.
 
 Ok, please compare du -k and du -k --apparent-size for each of the
@@ -38,6 +50,7 @@ files involved in the postgres run.
 
 -chris
 --
-To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
+To unsubscribe from this list: send the line "unsubscribe linux-ext4" i=
+n
 the body of a message to majordomo@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 15c0e4a..de49512 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -31,38 +31,50 @@
  "\00:1\0"
  "b\0"
  "Excerpts from Jon Nelson's message of 2010-12-07 15:25:47 -0500:\n"
- "> On Tue, Dec 7, 2010 at 2:02 PM, Chris Mason <chris.mason@oracle.com> wrote:\n"
+ "> On Tue, Dec 7, 2010 at 2:02 PM, Chris Mason <chris.mason@oracle.com> =\n"
+ "wrote:\n"
  "> > Excerpts from Jon Nelson's message of 2010-12-07 14:34:40 -0500:\n"
- "> >> On Tue, Dec 7, 2010 at 12:52 PM, Chris Mason <chris.mason@oracle.com> wrote:\n"
- "> >> >> postgresql errors. Typically, header corruption but from the limited\n"
- "> >> >> visibility I've had into this via strace, what I see is zeroed pages\n"
+ "> >> On Tue, Dec 7, 2010 at 12:52 PM, Chris Mason <chris.mason@oracle.c=\n"
+ "om> wrote:\n"
+ "> >> >> postgresql errors. Typically, header corruption but from the li=\n"
+ "mited\n"
+ "> >> >> visibility I've had into this via strace, what I see is zeroed =\n"
+ "pages\n"
  "> >> >> where there shouldn't be.\n"
  "> >> >\n"
- "> >> > This sounds a lot like a bug higher up than dm-crypt. \303\202\302\240Zeros tend to\n"
- "> >> > come from some piece of code explicitly filling a page with zeros, and\n"
- "> >> > that often happens in the corner cases for O_DIRECT and a few other\n"
+ "> >> > This sounds a lot like a bug higher up than dm-crypt. =C2=A0Zero=\n"
+ "s tend to\n"
+ "> >> > come from some piece of code explicitly filling a page with zero=\n"
+ "s, and\n"
+ "> >> > that often happens in the corner cases for O_DIRECT and a few ot=\n"
+ "her\n"
  "> >> > places in the filesystem.\n"
  "> >> >\n"
  "> >> > Have you tried triggering this with a regular block device?\n"
  "> >>\n"
- "> >> I just tried the whole set of tests, but with /dev/sdb directly (as\n"
+ "> >> I just tried the whole set of tests, but with /dev/sdb directly (a=\n"
+ "s\n"
  "> >> ext4) without any crypt-y bits.\n"
- "> >> It takes more iterations but out of 6 tests I had one failure: same\n"
+ "> >> It takes more iterations but out of 6 tests I had one failure: sam=\n"
+ "e\n"
  "> >> type of thing, 'invalid page header in block ....'.\n"
  "> >>\n"
- "> >> I can't guarantee that it is a full-page of zeroes, just what I saw\n"
+ "> >> I can't guarantee that it is a full-page of zeroes, just what I sa=\n"
+ "w\n"
  "> >> from the (limited) stracing I did.\n"
  "> >\n"
  "> > Fantastic. Now for our usual suspects:\n"
  "> >\n"
- "> > 1) Is postgres using O_DIRECT? \303\202\302\240If yes, please turn it off\n"
- "> \n"
+ "> > 1) Is postgres using O_DIRECT? =C2=A0If yes, please turn it off\n"
+ ">=20\n"
  "> According to strace, O_DIRECT didn't show up once during the test.\n"
- "> \n"
- "> > 2) Is postgres allocating sparse files? \303\202\302\240If yes, please have it fully\n"
+ ">=20\n"
+ "> > 2) Is postgres allocating sparse files? =C2=A0If yes, please have i=\n"
+ "t fully\n"
  "> > allocate the file instead.\n"
- "> \n"
- "> That's a tough one. I don't think postgresql does that, but I'm not an\n"
+ ">=20\n"
+ "> That's a tough one. I don't think postgresql does that, but I'm not a=\n"
+ "n\n"
  "> expert here.\n"
  "\n"
  "Ok, please compare du -k and du -k --apparent-size for each of the\n"
@@ -70,8 +82,9 @@
  "\n"
  "-chris\n"
  "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-ext4\" in\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-ext4\" i=\n"
+ "n\n"
  "the body of a message to majordomo@vger.kernel.org\n"
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-3fc6615d5efd8069b79b8047a8c3caf91bb92d8d114cd4fd591cd4bf78045cb3
+634a7a74a94a3313546db48a92465464c9776d7b308ee4ad09f891f5c344da02

diff --git a/a/1.txt b/N2/1.txt
index e51d352..8efda37 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -6,7 +6,7 @@ Excerpts from Jon Nelson's message of 2010-12-07 15:25:47 -0500:
 > >> >> visibility I've had into this via strace, what I see is zeroed pages
 > >> >> where there shouldn't be.
 > >> >
-> >> > This sounds a lot like a bug higher up than dm-crypt.  Zeros tend to
+> >> > This sounds a lot like a bug higher up than dm-crypt.  Zeros tend to
 > >> > come from some piece of code explicitly filling a page with zeros, and
 > >> > that often happens in the corner cases for O_DIRECT and a few other
 > >> > places in the filesystem.
@@ -23,11 +23,11 @@ Excerpts from Jon Nelson's message of 2010-12-07 15:25:47 -0500:
 > >
 > > Fantastic. Now for our usual suspects:
 > >
-> > 1) Is postgres using O_DIRECT?  If yes, please turn it off
+> > 1) Is postgres using O_DIRECT?  If yes, please turn it off
 > 
 > According to strace, O_DIRECT didn't show up once during the test.
 > 
-> > 2) Is postgres allocating sparse files?  If yes, please have it fully
+> > 2) Is postgres allocating sparse files?  If yes, please have it fully
 > > allocate the file instead.
 > 
 > That's a tough one. I don't think postgresql does that, but I'm not an
@@ -37,7 +37,3 @@ Ok, please compare du -k and du -k --apparent-size for each of the
 files involved in the postgres run.
 
 -chris
---
-To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N2/content_digest
index 15c0e4a..5b9cb0b 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -38,7 +38,7 @@
  "> >> >> visibility I've had into this via strace, what I see is zeroed pages\n"
  "> >> >> where there shouldn't be.\n"
  "> >> >\n"
- "> >> > This sounds a lot like a bug higher up than dm-crypt. \303\202\302\240Zeros tend to\n"
+ "> >> > This sounds a lot like a bug higher up than dm-crypt. \302\240Zeros tend to\n"
  "> >> > come from some piece of code explicitly filling a page with zeros, and\n"
  "> >> > that often happens in the corner cases for O_DIRECT and a few other\n"
  "> >> > places in the filesystem.\n"
@@ -55,11 +55,11 @@
  "> >\n"
  "> > Fantastic. Now for our usual suspects:\n"
  "> >\n"
- "> > 1) Is postgres using O_DIRECT? \303\202\302\240If yes, please turn it off\n"
+ "> > 1) Is postgres using O_DIRECT? \302\240If yes, please turn it off\n"
  "> \n"
  "> According to strace, O_DIRECT didn't show up once during the test.\n"
  "> \n"
- "> > 2) Is postgres allocating sparse files? \303\202\302\240If yes, please have it fully\n"
+ "> > 2) Is postgres allocating sparse files? \302\240If yes, please have it fully\n"
  "> > allocate the file instead.\n"
  "> \n"
  "> That's a tough one. I don't think postgresql does that, but I'm not an\n"
@@ -68,10 +68,6 @@
  "Ok, please compare du -k and du -k --apparent-size for each of the\n"
  "files involved in the postgres run.\n"
  "\n"
- "-chris\n"
- "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-ext4\" in\n"
- "the body of a message to majordomo@vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ -chris
 
-3fc6615d5efd8069b79b8047a8c3caf91bb92d8d114cd4fd591cd4bf78045cb3
+abf8a4c4c1cd2a3ffa912708bde1a4b0ffc1d8c0d0ef833a971f55387c7005de

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.