diff for duplicates of <1532438540.9819.2.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index a285f38..225a6ec 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -198,9 +198,3 @@ multipath. It has to be the multiple partitions, but we should test on non NVME with multiple partitions in the lab setup I guess to make sure - - --- -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 d3bbba5..d42668a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,9 +6,9 @@ "Date\0Tue, 24 Jul 2018 09:22:20 -0400\0" "To\0Mike Snitzer <snitzer@redhat.com>" " Hannes Reinecke <hare@suse.de>\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 09:07 -0400, Mike Snitzer wrote:\n" @@ -210,12 +210,6 @@ "multipath.\n" "\n" "It has to be the multiple partitions, but we should test on non NVME\n" - "with multiple partitions in the lab setup I guess to make sure\n" - "\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + with multiple partitions in the lab setup I guess to make sure -fa589152165b48758ad9d15ebb8715b28d90ae504ab676ec3bdcbdcba0baa799 +f551b302d0e6a4ab66b3191ba7f3eaf0e60e57d86b991b2cea325f36f785fc44
diff --git a/a/1.txt b/N2/1.txt index a285f38..9e5f8f6 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,5 +1,5 @@ -On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer wrote: -> On Tue, Jul 24 2018 at 2:00am -0400, +On Tue, 2018-07-24@09:07 -0400, Mike Snitzer wrote: +> 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: @@ -14,15 +14,15 @@ On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer 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 @@ -38,7 +38,7 @@ On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer 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 @@ -49,10 +49,10 @@ On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer 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 the +> 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 > whole NVMe device: @@ -66,66 +66,66 @@ On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer 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? > > 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: > -> drivers/md/dm-linear.c | 45 +> ?drivers/md/dm-linear.c | 45 > ++++++++++++++++++++++++++++++++++++++++++--- -> 1 file changed, 42 insertions(+), 3 deletions(-) +> ?1 file changed, 42 insertions(+), 3 deletions(-) > > diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c > index d10964d41fd7..d4a65dd20c6e 100644 > --- a/drivers/md/dm-linear.c > +++ b/drivers/md/dm-linear.c > @@ -12,6 +12,7 @@ -> #include <linux/dax.h> -> #include <linux/slab.h> -> #include <linux/device-mapper.h> +> ?#include <linux/dax.h> +> ?#include <linux/slab.h> +> ?#include <linux/device-mapper.h> > +#include <linux/blk-mq.h> -> -> #define DM_MSG_PREFIX "linear" -> +> ? +> ?#define DM_MSG_PREFIX "linear" +> ? > @@ -24,7 +25,7 @@ struct linear_c { -> }; -> -> /* +> ?}; +> ? +> ?/* > - * Construct a linear mapping: <dev_path> <offset> > + * Construct a linear mapping: <dev_path> <offset> [<# optional > params> <optional params>] -> */ -> static int linear_ctr(struct dm_target *ti, unsigned int argc, char +> ? */ +> ?static int linear_ctr(struct dm_target *ti, unsigned int argc, char > **argv) -> { +> ?{ > @@ -57,6 +58,11 @@ static int linear_ctr(struct dm_target *ti, > unsigned int argc, char **argv) -> goto bad; -> } -> +> ? goto bad; +> ? } +> ? > + // FIXME: need to parse optional args -> + // FIXME: model alloc_multipath_stage2()? +> + // FIXME: model??alloc_multipath_stage2()? > + // Call: dm_table_set_type() > + dm_table_set_type(ti->table, DM_TYPE_MQ_REQUEST_BASED); > + -> ti->num_flush_bios = 1; -> ti->num_discard_bios = 1; -> ti->num_secure_erase_bios = 1; +> ? ti->num_flush_bios = 1; +> ? ti->num_discard_bios = 1; +> ? ti->num_secure_erase_bios = 1; > @@ -113,6 +119,37 @@ static int linear_end_io(struct dm_target *ti, > struct bio *bio, -> return DM_ENDIO_DONE; -> } -> +> ? return DM_ENDIO_DONE; +> ?} +> ? > +static int linear_clone_and_map(struct dm_target *ti, struct request > *rq, > + union map_info *map_context, @@ -159,30 +159,30 @@ On Tue, 2018-07-24 at 09:07 -0400, Mike Snitzer wrote: > + blk_put_request(clone); > +} > + -> static void linear_status(struct dm_target *ti, status_type_t type, -> unsigned status_flags, char *result, +> ?static void linear_status(struct dm_target *ti, status_type_t type, +> ? ??unsigned status_flags, char *result, > unsigned maxlen) -> { +> ?{ > @@ -207,13 +244,15 @@ static size_t linear_dax_copy_to_iter(struct > dm_target *ti, pgoff_t pgoff, -> -> static struct target_type linear_target = { -> .name = "linear", +> ? +> ?static struct target_type linear_target = { +> ? .name???= "linear", > - .version = {1, 4, 0}, > - .features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM, > + .version = {1, 5, 0}, > + .features = DM_TARGET_IMMUTABLE | DM_TARGET_PASSES_INTEGRITY > | DM_TARGET_ZONED_HM, -> .module = THIS_MODULE, -> .ctr = linear_ctr, -> .dtr = linear_dtr, -> .map = linear_map, -> .end_io = linear_end_io, +> ? .module = THIS_MODULE, +> ? .ctr????= linear_ctr, +> ? .dtr????= linear_dtr, +> ? .map????= linear_map, +> ? .end_io = linear_end_io, > + .clone_and_map_rq = linear_clone_and_map, > + .release_clone_rq = linear_release_clone, -> .status = linear_status, -> .prepare_ioctl = linear_prepare_ioctl, -> .iterate_devices = linear_iterate_devices, +> ? .status = linear_status, +> ? .prepare_ioctl = linear_prepare_ioctl, +> ? .iterate_devices = linear_iterate_devices, > > > @@ -198,9 +198,3 @@ multipath. It has to be the multiple partitions, but we should test on non NVME with multiple partitions in the lab setup I guess to make sure - - --- -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 d3bbba5..9247603 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,18 +1,13 @@ "ref\020180723163357.GA29658@redhat.com\0" "ref\0e761830f-e3f7-3e88-1697-b4b150e84e5f@suse.de\0" "ref\020180724130703.GA30804@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 09:22:20 -0400\0" - "To\0Mike Snitzer <snitzer@redhat.com>" - " Hannes Reinecke <hare@suse.de>\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 09:07 -0400, Mike Snitzer wrote:\n" - "> On Tue, Jul 24 2018 at\302\240\302\2402:00am -0400,\n" + "On Tue, 2018-07-24@09:07 -0400, Mike Snitzer wrote:\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" @@ -27,15 +22,15 @@ "> > > \n" "> > > But otherwise, happy to get as much feedback and discussion going\n" "> > > 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 and\n" "> > > is\n" @@ -51,7 +46,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" @@ -62,10 +57,10 @@ "> > \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 whole\n" - "> NVMe device is overwritten by XFS.\302\240\302\240So likely the IO destined to the\n" + "> NVMe device is overwritten by XFS.??So likely the IO destined to the\n" "> dm-cache's \"slow\" (dm-mpath device on NVMe partition) was issued to\n" "> the\n" "> whole NVMe device:\n" @@ -79,66 +74,66 @@ "> WARNING: xfs signature detected on /dev/test/slow at offset 0. Wipe\n" "> it?\n" "> [y/n]: y\n" - "> \302\240 Wiping xfs signature on /dev/test/slow.\n" - "> \302\240 Logical 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" "> 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" - "> \302\240drivers/md/dm-linear.c | 45\n" + "> ?drivers/md/dm-linear.c | 45\n" "> ++++++++++++++++++++++++++++++++++++++++++---\n" - "> \302\2401 file changed, 42 insertions(+), 3 deletions(-)\n" + "> ?1 file changed, 42 insertions(+), 3 deletions(-)\n" "> \n" "> diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c\n" "> index d10964d41fd7..d4a65dd20c6e 100644\n" "> --- a/drivers/md/dm-linear.c\n" "> +++ b/drivers/md/dm-linear.c\n" "> @@ -12,6 +12,7 @@\n" - "> \302\240#include <linux/dax.h>\n" - "> \302\240#include <linux/slab.h>\n" - "> \302\240#include <linux/device-mapper.h>\n" + "> ?#include <linux/dax.h>\n" + "> ?#include <linux/slab.h>\n" + "> ?#include <linux/device-mapper.h>\n" "> +#include <linux/blk-mq.h>\n" - "> \302\240\n" - "> \302\240#define DM_MSG_PREFIX \"linear\"\n" - "> \302\240\n" + "> ?\n" + "> ?#define DM_MSG_PREFIX \"linear\"\n" + "> ?\n" "> @@ -24,7 +25,7 @@ struct linear_c {\n" - "> \302\240};\n" - "> \302\240\n" - "> \302\240/*\n" + "> ?};\n" + "> ?\n" + "> ?/*\n" "> - * Construct a linear mapping: <dev_path> <offset>\n" "> + * Construct a linear mapping: <dev_path> <offset> [<# optional\n" "> params> <optional params>]\n" - "> \302\240 */\n" - "> \302\240static int linear_ctr(struct dm_target *ti, unsigned int argc, char\n" + "> ? */\n" + "> ?static int linear_ctr(struct dm_target *ti, unsigned int argc, char\n" "> **argv)\n" - "> \302\240{\n" + "> ?{\n" "> @@ -57,6 +58,11 @@ static int linear_ctr(struct dm_target *ti,\n" "> unsigned int argc, char **argv)\n" - "> \302\240\t\tgoto bad;\n" - "> \302\240\t}\n" - "> \302\240\n" + "> ?\t\tgoto bad;\n" + "> ?\t}\n" + "> ?\n" "> +\t// FIXME: need to parse optional args\n" - "> +\t// FIXME: model\302\240\302\240alloc_multipath_stage2()?\n" + "> +\t// FIXME: model??alloc_multipath_stage2()?\n" "> +\t// Call: dm_table_set_type()\n" "> +\tdm_table_set_type(ti->table, DM_TYPE_MQ_REQUEST_BASED);\n" "> +\n" - "> \302\240\tti->num_flush_bios = 1;\n" - "> \302\240\tti->num_discard_bios = 1;\n" - "> \302\240\tti->num_secure_erase_bios = 1;\n" + "> ?\tti->num_flush_bios = 1;\n" + "> ?\tti->num_discard_bios = 1;\n" + "> ?\tti->num_secure_erase_bios = 1;\n" "> @@ -113,6 +119,37 @@ static int linear_end_io(struct dm_target *ti,\n" "> struct bio *bio,\n" - "> \302\240\treturn DM_ENDIO_DONE;\n" - "> \302\240}\n" - "> \302\240\n" + "> ?\treturn DM_ENDIO_DONE;\n" + "> ?}\n" + "> ?\n" "> +static int linear_clone_and_map(struct dm_target *ti, struct request\n" "> *rq,\n" "> +\t\t\t\tunion map_info *map_context,\n" @@ -172,30 +167,30 @@ "> +\tblk_put_request(clone);\n" "> +}\n" "> +\n" - "> \302\240static void linear_status(struct dm_target *ti, status_type_t type,\n" - "> \302\240\t\t\t\302\240\302\240unsigned status_flags, char *result,\n" + "> ?static void linear_status(struct dm_target *ti, status_type_t type,\n" + "> ?\t\t\t??unsigned status_flags, char *result,\n" "> unsigned maxlen)\n" - "> \302\240{\n" + "> ?{\n" "> @@ -207,13 +244,15 @@ static size_t linear_dax_copy_to_iter(struct\n" "> dm_target *ti, pgoff_t pgoff,\n" - "> \302\240\n" - "> \302\240static struct target_type linear_target = {\n" - "> \302\240\t.name\302\240\302\240\302\240= \"linear\",\n" + "> ?\n" + "> ?static struct target_type linear_target = {\n" + "> ?\t.name???= \"linear\",\n" "> -\t.version = {1, 4, 0},\n" "> -\t.features = DM_TARGET_PASSES_INTEGRITY | DM_TARGET_ZONED_HM,\n" "> +\t.version = {1, 5, 0},\n" "> +\t.features = DM_TARGET_IMMUTABLE | DM_TARGET_PASSES_INTEGRITY\n" "> | DM_TARGET_ZONED_HM,\n" - "> \302\240\t.module = THIS_MODULE,\n" - "> \302\240\t.ctr\302\240\302\240\302\240\302\240= linear_ctr,\n" - "> \302\240\t.dtr\302\240\302\240\302\240\302\240= linear_dtr,\n" - "> \302\240\t.map\302\240\302\240\302\240\302\240= linear_map,\n" - "> \302\240\t.end_io = linear_end_io,\n" + "> ?\t.module = THIS_MODULE,\n" + "> ?\t.ctr????= linear_ctr,\n" + "> ?\t.dtr????= linear_dtr,\n" + "> ?\t.map????= linear_map,\n" + "> ?\t.end_io = linear_end_io,\n" "> +\t.clone_and_map_rq = linear_clone_and_map,\n" "> +\t.release_clone_rq = linear_release_clone,\n" - "> \302\240\t.status = linear_status,\n" - "> \302\240\t.prepare_ioctl = linear_prepare_ioctl,\n" - "> \302\240\t.iterate_devices = linear_iterate_devices,\n" + "> ?\t.status = linear_status,\n" + "> ?\t.prepare_ioctl = linear_prepare_ioctl,\n" + "> ?\t.iterate_devices = linear_iterate_devices,\n" "> \n" "> \n" "> \n" @@ -210,12 +205,6 @@ "multipath.\n" "\n" "It has to be the multiple partitions, but we should test on non NVME\n" - "with multiple partitions in the lab setup I guess to make sure\n" - "\n" - "\n" - "--\n" - "dm-devel mailing list\n" - "dm-devel@redhat.com\n" - https://www.redhat.com/mailman/listinfo/dm-devel + with multiple partitions in the lab setup I guess to make sure -fa589152165b48758ad9d15ebb8715b28d90ae504ab676ec3bdcbdcba0baa799 +43a7f624a4fe740d37fb44059eae2f79b155c8027a7b3af26b77c8ff39755a53
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.