diff for duplicates of <1532440623.9819.4.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index a06a813..2566a0c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -110,8 +110,3 @@ This came about because a customer is using nvme for a dm-cache device and created multiple partitions so as to use the same nvme to cache multiple different "slower" devices. The corruption was noticed in XFS and I engaged Mike to assist in figuring out what was going on. - --- -dm-devel mailing list -dm-devel@redhat.com -https://www.redhat.com/mailman/listinfo/dm-devel diff --git a/a/content_digest b/N1/content_digest index 377cb03..fb80703 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,9 +7,9 @@ "Date\0Tue, 24 Jul 2018 09:57:03 -0400\0" "To\0Hannes Reinecke <hare@suse.de>" " Mike Snitzer <snitzer@redhat.com>\0" - "Cc\0linux-block@vger.kernel.org" - dm-devel@redhat.com - " linux-nvme@lists.infradead.org\0" + "Cc\0linux-nvme@lists.infradead.org" + linux-block@vger.kernel.org + " dm-devel@redhat.com\0" "\00:1\0" "b\0" "On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote:\n" @@ -123,11 +123,6 @@ "This came about because a customer is using nvme for a dm-cache device\n" "and created multiple partitions so as to use the same nvme to cache\n" "multiple different \"slower\" devices. The corruption was noticed in XFS\n" - "and I engaged Mike to assist in figuring out what was going on.\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + and I engaged Mike to assist in figuring out what was going on. -87429ac05a272d338f235a21007aa86f6f211897dbe7158db18ffc20d8cf2745 +fc1ccbd019fbf922fcfc5289ea387fe26a02d66c97aac892f485322ec1b5f78d
diff --git a/a/1.txt b/N2/1.txt index a06a813..8c8b748 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,6 +1,6 @@ -On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: +On Tue, 2018-07-24@15:51 +0200, Hannes Reinecke wrote: > On 07/24/2018 03:07 PM, Mike Snitzer wrote: -> > On Tue, Jul 24 2018 at 2:00am -0400, +> > On Tue, Jul 24 2018 at??2:00am -0400, > > Hannes Reinecke <hare@suse.de> wrote: > > > > > On 07/23/2018 06:33 PM, Mike Snitzer wrote: @@ -15,15 +15,15 @@ On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: > > > > > > > > But otherwise, happy to get as much feedback and discussion > > > > going purely -> > > > on the relevant lists. I've taken ~1.5 weeks to categorize and +> > > > on the relevant lists.??I've taken ~1.5 weeks to categorize and > > > > isolate -> > > > this issue. But I've reached a point where I'm getting +> > > > this issue.??But I've reached a point where I'm getting > > > > diminishing > > > > returns and could _really_ use the collective eyeballs and > > > > expertise of -> > > > the community. This is by far one of the most nasty cases of +> > > > the community.??This is by far one of the most nasty cases of > > > > corruption -> > > > I've seen in a while. Not sure where the ultimate cause of +> > > > I've seen in a while.??Not sure where the ultimate cause of > > > > corruption > > > > lies (that the money question) but it _feels_ rooted in NVMe > > > > and is @@ -40,7 +40,7 @@ On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: > > > To my knowledge we've never tested that when running on a > > > partition. > > -> > True. We only ever support mapping the partitions ontop of +> > True.??We only ever support mapping the partitions ontop of > > request-based multipath (via dm-linear volumes created by kpartx). > > > > > So, have you tested that request-based multipathing works on a @@ -52,11 +52,11 @@ On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: > > > > > > Have you checked that partition remapping is done correctly? > > -> > It clearly doesn't work. Not quite following why but... +> > It clearly doesn't work.??Not quite following why but... > > > > After running the test the partition table at the start of the > > whole -> > NVMe device is overwritten by XFS. So likely the IO destined to +> > NVMe device is overwritten by XFS.??So likely the IO destined to > > the > > dm-cache's "slow" (dm-mpath device on NVMe partition) was issued to > > the @@ -71,34 +71,34 @@ On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: > > WARNING: xfs signature detected on /dev/test/slow at offset 0. Wipe > > it? > > [y/n]: y -> > Wiping xfs signature on /dev/test/slow. -> > Logical volume "slow" created. +> > ???Wiping xfs signature on /dev/test/slow. +> > ???Logical volume "slow" created. > > -> > Isn't this a failing of block core's partitioning? Why should a +> > Isn't this a failing of block core's partitioning???Why should a > > target > > that is given the entire partition of a device need to be concerned > > with -> > remapping IO? Shouldn't block core handle that mapping? +> > remapping IO???Shouldn't block core handle that mapping? > > > -> Only if the device is marked a 'partitionable', which device-mapper +> Only if the device is marked a 'partitionable', which device-mapper? > devices are not. > But I thought you knew that ... > > > Anyway, yesterday I went so far as to hack together request-based > > support for DM linear (because request-based DM cannot stack on -> > bio-based DM) . With this, request-based linear devices instead of +> > bio-based DM) .??With this, request-based linear devices instead of > > conventional partitioning, I no longer see the XFS corruption when > > running the test: > > > > _Actually_, I would've done it the other way around; after all, -> where't +> where't? > the point in running dm-multipath on a partition? > Anything running on the other partitions would suffer from the -> issues +> issues? > dm-multipath is designed to handle (temporary path loss etc), so I'm -> not +> not? > quite sure what you are trying to achieve with your testcase. > Can you enlighten me? > @@ -110,8 +110,3 @@ This came about because a customer is using nvme for a dm-cache device and created multiple partitions so as to use the same nvme to cache multiple different "slower" devices. The corruption was noticed in XFS and I engaged Mike to assist in figuring out what was going on. - --- -dm-devel mailing list -dm-devel@redhat.com -https://www.redhat.com/mailman/listinfo/dm-devel diff --git a/a/content_digest b/N2/content_digest index 377cb03..4cb7e71 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -2,19 +2,14 @@ "ref\0e761830f-e3f7-3e88-1697-b4b150e84e5f@suse.de\0" "ref\020180724130703.GA30804@redhat.com\0" "ref\027cadfb3-2442-3931-6d58-58aa6adb2e2b@suse.de\0" - "From\0Laurence Oberman <loberman@redhat.com>\0" - "Subject\0Re: data corruption with 'splt' workload to XFS on DM cache with its 3 underlying devices being on same NVMe device\0" + "From\0loberman@redhat.com (Laurence Oberman)\0" + "Subject\0data corruption with 'splt' workload to XFS on DM cache with its 3 underlying devices being on same NVMe device\0" "Date\0Tue, 24 Jul 2018 09:57:03 -0400\0" - "To\0Hannes Reinecke <hare@suse.de>" - " Mike Snitzer <snitzer@redhat.com>\0" - "Cc\0linux-block@vger.kernel.org" - dm-devel@redhat.com - " linux-nvme@lists.infradead.org\0" "\00:1\0" "b\0" - "On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote:\n" + "On Tue, 2018-07-24@15:51 +0200, Hannes Reinecke wrote:\n" "> On 07/24/2018 03:07 PM, Mike Snitzer wrote:\n" - "> > On Tue, Jul 24 2018 at\302\240\302\2402:00am -0400,\n" + "> > On Tue, Jul 24 2018 at??2:00am -0400,\n" "> > Hannes Reinecke <hare@suse.de> wrote:\n" "> > \n" "> > > On 07/23/2018 06:33 PM, Mike Snitzer wrote:\n" @@ -29,15 +24,15 @@ "> > > > \n" "> > > > But otherwise, happy to get as much feedback and discussion\n" "> > > > going purely\n" - "> > > > on the relevant lists.\302\240\302\240I've taken ~1.5 weeks to categorize and\n" + "> > > > on the relevant lists.??I've taken ~1.5 weeks to categorize and\n" "> > > > isolate\n" - "> > > > this issue.\302\240\302\240But I've reached a point where I'm getting\n" + "> > > > this issue.??But I've reached a point where I'm getting\n" "> > > > diminishing\n" "> > > > returns and could _really_ use the collective eyeballs and\n" "> > > > expertise of\n" - "> > > > the community.\302\240\302\240This is by far one of the most nasty cases of\n" + "> > > > the community.??This is by far one of the most nasty cases of\n" "> > > > corruption\n" - "> > > > I've seen in a while.\302\240\302\240Not sure where the ultimate cause of\n" + "> > > > I've seen in a while.??Not sure where the ultimate cause of\n" "> > > > corruption\n" "> > > > lies (that the money question) but it _feels_ rooted in NVMe\n" "> > > > and is\n" @@ -54,7 +49,7 @@ "> > > To my knowledge we've never tested that when running on a\n" "> > > partition.\n" "> > \n" - "> > True.\302\240\302\240We only ever support mapping the partitions ontop of\n" + "> > True.??We only ever support mapping the partitions ontop of\n" "> > request-based multipath (via dm-linear volumes created by kpartx).\n" "> > \n" "> > > So, have you tested that request-based multipathing works on a\n" @@ -66,11 +61,11 @@ "> > > \n" "> > > Have you checked that partition remapping is done correctly?\n" "> > \n" - "> > It clearly doesn't work.\302\240\302\240Not quite following why but...\n" + "> > It clearly doesn't work.??Not quite following why but...\n" "> > \n" "> > After running the test the partition table at the start of the\n" "> > whole\n" - "> > NVMe device is overwritten by XFS.\302\240\302\240So likely the IO destined to\n" + "> > NVMe device is overwritten by XFS.??So likely the IO destined to\n" "> > the\n" "> > dm-cache's \"slow\" (dm-mpath device on NVMe partition) was issued to\n" "> > the\n" @@ -85,34 +80,34 @@ "> > WARNING: xfs signature detected on /dev/test/slow at offset 0. Wipe\n" "> > it?\n" "> > [y/n]: y\n" - "> > \302\240\302\240\302\240Wiping xfs signature on /dev/test/slow.\n" - "> > \302\240\302\240\302\240Logical volume \"slow\" created.\n" + "> > ???Wiping xfs signature on /dev/test/slow.\n" + "> > ???Logical volume \"slow\" created.\n" "> > \n" - "> > Isn't this a failing of block core's partitioning?\302\240\302\240Why should a\n" + "> > Isn't this a failing of block core's partitioning???Why should a\n" "> > target\n" "> > that is given the entire partition of a device need to be concerned\n" "> > with\n" - "> > remapping IO?\302\240\302\240Shouldn't block core handle that mapping?\n" + "> > remapping IO???Shouldn't block core handle that mapping?\n" "> > \n" "> \n" - "> Only if the device is marked a 'partitionable', which device-mapper\302\240\n" + "> Only if the device is marked a 'partitionable', which device-mapper?\n" "> devices are not.\n" "> But I thought you knew that ...\n" "> \n" "> > Anyway, yesterday I went so far as to hack together request-based\n" "> > support for DM linear (because request-based DM cannot stack on\n" - "> > bio-based DM) .\302\240\302\240With this, request-based linear devices instead of\n" + "> > bio-based DM) .??With this, request-based linear devices instead of\n" "> > conventional partitioning, I no longer see the XFS corruption when\n" "> > running the test:\n" "> > \n" "> \n" "> _Actually_, I would've done it the other way around; after all,\n" - "> where't\302\240\n" + "> where't?\n" "> the point in running dm-multipath on a partition?\n" "> Anything running on the other partitions would suffer from the\n" - "> issues\302\240\n" + "> issues?\n" "> dm-multipath is designed to handle (temporary path loss etc), so I'm\n" - "> not\302\240\n" + "> not?\n" "> quite sure what you are trying to achieve with your testcase.\n" "> Can you enlighten me?\n" "> \n" @@ -123,11 +118,6 @@ "This came about because a customer is using nvme for a dm-cache device\n" "and created multiple partitions so as to use the same nvme to cache\n" "multiple different \"slower\" devices. The corruption was noticed in XFS\n" - "and I engaged Mike to assist in figuring out what was going on.\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + and I engaged Mike to assist in figuring out what was going on. -87429ac05a272d338f235a21007aa86f6f211897dbe7158db18ffc20d8cf2745 +08e8255086a1e8aa23b5abd810f9e8c74f44162ce598302c0d2add32b32a683c
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.