diff for duplicates of <1532446308.9819.7.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 9b7d10f..07288aa 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -84,8 +84,3 @@ cache_FC-fc_disk (253:45) │ └─ (259:2) └─cache_FC-nvme_blk_cache_cmeta (253:43) └─ (259:2) - --- -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 253e2a4..c488ad5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,10 +9,10 @@ "Date\0Tue, 24 Jul 2018 11:31:48 -0400\0" "To\0Mike Snitzer <snitzer@redhat.com>" " Hannes Reinecke <hare@suse.de>\0" - "Cc\0linux-block@vger.kernel.org" - Brett Hull <bhull@redhat.com> + "Cc\0linux-nvme@lists.infradead.org" + linux-block@vger.kernel.org dm-devel@redhat.com - " linux-nvme@lists.infradead.org\0" + " Brett Hull <bhull@redhat.com>\0" "\00:1\0" "b\0" "On Tue, 2018-07-24 at 11:18 -0400, Mike Snitzer wrote:\n" @@ -100,11 +100,6 @@ "\302\240\342\224\234\342\224\200cache_FC-nvme_blk_cache_cdata (253:42)\n" "\302\240\342\224\202\302\240\302\240\342\224\224\342\224\200 (259:2)\n" "\302\240\342\224\224\342\224\200cache_FC-nvme_blk_cache_cmeta (253:43)\n" - "\302\240\302\240\302\240\302\240\342\224\224\342\224\200 (259:2)\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + "\302\240\302\240\302\240\302\240\342\224\224\342\224\200 (259:2)" -1ce39863b61dbaef4573defd980c922be392a83424944210d479a29229875260 +1df40b0f6cfc553d09c4532b722549959e1438a34d61dcc3e67e0bf0f0a7785b
diff --git a/a/1.txt b/N2/1.txt index 9b7d10f..6fed8fc 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,8 +1,8 @@ -On Tue, 2018-07-24 at 11:18 -0400, Mike Snitzer wrote: -> On Tue, Jul 24 2018 at 9:57am -0400, +On Tue, 2018-07-24@11:18 -0400, Mike Snitzer wrote: +> On Tue, Jul 24 2018 at??9:57am -0400, > Laurence Oberman <loberman@redhat.com> wrote: > -> > On Tue, 2018-07-24 at 15:51 +0200, Hannes Reinecke wrote: +> > On Tue, 2018-07-24@15:51 +0200, Hannes Reinecke wrote: > > > > > > _Actually_, I would've done it the other way around; after all, > > > where't the point in running dm-multipath on a partition? @@ -18,7 +18,7 @@ On Tue, 2018-07-24 at 11:18 -0400, Mike Snitzer wrote: > > I wasn't looking to deply this (multipath on partition) in production > or -> suggest it to others. It was a means to experiment. More below. +> suggest it to others.??It was a means to experiment.??More below. > > > This came about because a customer is using nvme for a dm-cache > > device @@ -31,7 +31,7 @@ On Tue, 2018-07-24 at 11:18 -0400, Mike Snitzer wrote: > > 1) MD raid1 on 2 NVMe partitions (from separate NVMe devices). > 2) Then DM cache's "fast" and "metadata" devices layered on dm-linear -> mapping ontop of the MD raid1. +> ???mapping ontop of the MD raid1. > 3) Then Ceph's rbd for DM-cache's slow device. > > I was just looking to simplify the stack to try to assess why XFS @@ -63,29 +63,24 @@ mapper-multipath LUNS cached via dm-cache. The last test we ran where we did not see corruption was a partition where the second partition was used to cache F/C luns -nvme0n1 259:0 0 372.6G 0 disk -├─nvme0n1p1 259:1 0 150G 0 part -└─nvme0n1p2 259:2 0 150G 0 part - ├─cache_FC-nvme_blk_cache_cdata 253:42 0 20G 0 lvm - │ └─cache_FC-fc_disk 253:45 0 48G 0 -lvm /cache_FC - └─cache_FC-nvme_blk_cache_cmeta 253:43 0 40M 0 lvm - └─cache_FC-fc_disk 253:45 0 48G 0 -lvm /cache_FC +nvme0n1?????????????????????????????259:0????0 372.6G??0 disk?? +??nvme0n1p1?????????????????????????259:1????0???150G??0 part?? +??nvme0n1p2?????????????????????????259:2????0???150G??0 part?? +? ??cache_FC-nvme_blk_cache_cdata???253:42???0????20G??0 lvm??? +? ? ??cache_FC-fc_disk??????????????253:45???0????48G??0 +lvm???/cache_FC +? ??cache_FC-nvme_blk_cache_cmeta???253:43???0????40M??0 lvm??? +??????cache_FC-fc_disk??????????????253:45???0????48G??0 +lvm???/cache_FC cache_FC-fc_disk (253:45) - ├─cache_FC-fc_disk_corig (253:44) - │ └─3600140508da66c2c9ee4cc6aface1bab (253:36) Multipath - │ ├─ (68:224) - │ ├─ (69:240) - │ ├─ (8:192) - │ └─ (8:64) - ├─cache_FC-nvme_blk_cache_cdata (253:42) - │ └─ (259:2) - └─cache_FC-nvme_blk_cache_cmeta (253:43) - └─ (259:2) - --- -dm-devel mailing list -dm-devel@redhat.com -https://www.redhat.com/mailman/listinfo/dm-devel +???cache_FC-fc_disk_corig (253:44) +??????3600140508da66c2c9ee4cc6aface1bab (253:36) Multipath +????????? (68:224) +????????? (69:240) +????????? (8:192) +????????? (8:64) +???cache_FC-nvme_blk_cache_cdata (253:42) +?????? (259:2) +???cache_FC-nvme_blk_cache_cmeta (253:43) +?????? (259:2) diff --git a/a/content_digest b/N2/content_digest index 253e2a4..034758a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,22 +4,16 @@ "ref\027cadfb3-2442-3931-6d58-58aa6adb2e2b@suse.de\0" "ref\01532440623.9819.4.camel@redhat.com\0" "ref\020180724151845.GB3235@redhat.com\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 11:31:48 -0400\0" - "To\0Mike Snitzer <snitzer@redhat.com>" - " Hannes Reinecke <hare@suse.de>\0" - "Cc\0linux-block@vger.kernel.org" - Brett Hull <bhull@redhat.com> - dm-devel@redhat.com - " linux-nvme@lists.infradead.org\0" "\00:1\0" "b\0" - "On Tue, 2018-07-24 at 11:18 -0400, Mike Snitzer wrote:\n" - "> On Tue, Jul 24 2018 at\302\240\302\2409:57am -0400,\n" + "On Tue, 2018-07-24@11:18 -0400, Mike Snitzer wrote:\n" + "> On Tue, Jul 24 2018 at??9:57am -0400,\n" "> Laurence Oberman <loberman@redhat.com> wrote:\n" "> \n" - "> > 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" "> > > \n" "> > > _Actually_, I would've done it the other way around; after all,\n" "> > > where't the point in running dm-multipath on a partition?\n" @@ -35,7 +29,7 @@ "> \n" "> I wasn't looking to deply this (multipath on partition) in production\n" "> or\n" - "> suggest it to others.\302\240\302\240It was a means to experiment.\302\240\302\240More below.\n" + "> suggest it to others.??It was a means to experiment.??More below.\n" "> \n" "> > This came about because a customer is using nvme for a dm-cache\n" "> > device\n" @@ -48,7 +42,7 @@ "> \n" "> 1) MD raid1 on 2 NVMe partitions (from separate NVMe devices).\n" "> 2) Then DM cache's \"fast\" and \"metadata\" devices layered on dm-linear\n" - "> \302\240\302\240\302\240mapping ontop of the MD raid1.\n" + "> ???mapping ontop of the MD raid1.\n" "> 3) Then Ceph's rbd for DM-cache's slow device.\n" "> \n" "> I was just looking to simplify the stack to try to assess why XFS\n" @@ -80,31 +74,26 @@ "The last test we ran where we did not see corruption was a partition\n" "where the second partition was used to cache F/C luns\n" "\n" - "nvme0n1\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240259:0\302\240\302\240\302\240\302\2400 372.6G\302\240\302\2400 disk\302\240\302\240\n" - "\342\224\234\342\224\200nvme0n1p1\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240259:1\302\240\302\240\302\240\302\2400\302\240\302\240\302\240150G\302\240\302\2400 part\302\240\302\240\n" - "\342\224\224\342\224\200nvme0n1p2\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240259:2\302\240\302\240\302\240\302\2400\302\240\302\240\302\240150G\302\240\302\2400 part\302\240\302\240\n" - "\302\240 \342\224\234\342\224\200cache_FC-nvme_blk_cache_cdata\302\240\302\240\302\240253:42\302\240\302\240\302\2400\302\240\302\240\302\240\302\24020G\302\240\302\2400 lvm\302\240\302\240\302\240\n" - "\302\240 \342\224\202 \342\224\224\342\224\200cache_FC-fc_disk\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240253:45\302\240\302\240\302\2400\302\240\302\240\302\240\302\24048G\302\240\302\2400\n" - "lvm\302\240\302\240\302\240/cache_FC\n" - "\302\240 \342\224\224\342\224\200cache_FC-nvme_blk_cache_cmeta\302\240\302\240\302\240253:43\302\240\302\240\302\2400\302\240\302\240\302\240\302\24040M\302\240\302\2400 lvm\302\240\302\240\302\240\n" - "\302\240\302\240\302\240\302\240\342\224\224\342\224\200cache_FC-fc_disk\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240253:45\302\240\302\240\302\2400\302\240\302\240\302\240\302\24048G\302\240\302\2400\n" - "lvm\302\240\302\240\302\240/cache_FC\n" + "nvme0n1?????????????????????????????259:0????0 372.6G??0 disk??\n" + "??nvme0n1p1?????????????????????????259:1????0???150G??0 part??\n" + "??nvme0n1p2?????????????????????????259:2????0???150G??0 part??\n" + "? ??cache_FC-nvme_blk_cache_cdata???253:42???0????20G??0 lvm???\n" + "? ? ??cache_FC-fc_disk??????????????253:45???0????48G??0\n" + "lvm???/cache_FC\n" + "? ??cache_FC-nvme_blk_cache_cmeta???253:43???0????40M??0 lvm???\n" + "??????cache_FC-fc_disk??????????????253:45???0????48G??0\n" + "lvm???/cache_FC\n" "\n" "cache_FC-fc_disk (253:45)\n" - "\302\240\342\224\234\342\224\200cache_FC-fc_disk_corig (253:44)\n" - "\302\240\342\224\202\302\240\302\240\342\224\224\342\224\2003600140508da66c2c9ee4cc6aface1bab (253:36) Multipath\n" - "\302\240\342\224\202\302\240\302\240\302\240\302\240\302\240\342\224\234\342\224\200 (68:224)\n" - "\302\240\342\224\202\302\240\302\240\302\240\302\240\302\240\342\224\234\342\224\200 (69:240)\n" - "\302\240\342\224\202\302\240\302\240\302\240\302\240\302\240\342\224\234\342\224\200 (8:192)\n" - "\302\240\342\224\202\302\240\302\240\302\240\302\240\302\240\342\224\224\342\224\200 (8:64)\n" - "\302\240\342\224\234\342\224\200cache_FC-nvme_blk_cache_cdata (253:42)\n" - "\302\240\342\224\202\302\240\302\240\342\224\224\342\224\200 (259:2)\n" - "\302\240\342\224\224\342\224\200cache_FC-nvme_blk_cache_cmeta (253:43)\n" - "\302\240\302\240\302\240\302\240\342\224\224\342\224\200 (259:2)\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + "???cache_FC-fc_disk_corig (253:44)\n" + "??????3600140508da66c2c9ee4cc6aface1bab (253:36) Multipath\n" + "????????? (68:224)\n" + "????????? (69:240)\n" + "????????? (8:192)\n" + "????????? (8:64)\n" + "???cache_FC-nvme_blk_cache_cdata (253:42)\n" + "?????? (259:2)\n" + "???cache_FC-nvme_blk_cache_cmeta (253:43)\n" + ?????? (259:2) -1ce39863b61dbaef4573defd980c922be392a83424944210d479a29229875260 +851dfde3b3811e4d748e4e75642998131547fc460cc78b043824879d0f1f2fd2
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.