From: Mike Snitzer <snitzer@redhat.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: dm: Fix report zone remapping
Date: Fri, 5 Oct 2018 23:49:47 -0400 [thread overview]
Message-ID: <20181006034946.GA7891@redhat.com> (raw)
In-Reply-To: <BN3PR0401MB1640B2763051334D011B0111E7E40@BN3PR0401MB1640.namprd04.prod.outlook.com>
On Fri, Oct 05 2018 at 9:24pm -0400,
Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> Mike,
>
> On 2018/10/06 3:29, Mike Snitzer wrote:
> > On Fri, Oct 05 2018 at 6:34am -0400,
> > Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >
> >> If dm-linear or dm-flakey have targets on top of a partition of a zoned
> >> block device, remapping of the start sector and write pointer position
> >> of the zones reported by a report zones BIO must be modified to not
> >> only account for the target table entry mapping, but also to account
> >> for the partition first sector. This start sector must be substracted
> >> to the start sector of all zones reported. The write pointer position
> >> of sequential zones must also be reduced by this offset.
> >>
> >> Since there is no easy way to access the underlying bdev of the target
> >> table entry from the dm_target or dm_target_io pointers, modify the
> >> interface of the function dm_remap_zone_report() to allow a target to
> >> pass the partition block device starting sector (offset).
> >>
> >> Fixes: 10999307c14e ("dm: introduce dm_remap_zone_report()")
> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >> Cc: <stable@vger.kernel.org>
> >
> > [dropping the actual stable cc from the mail, please don't cc stable in
> > the mail header, could be that git-send-email just pulled it in but...]
>
> My apologies about that. It was indeed git-send-email. Will fix that.
>
> > This needs a different fix. There should be absolutely no need to pass
> > in a start offset for a device that is already supposed to be described
> > within the 'struct bio' passed to dm_remap_zone_report().
> >
> > Why can't you just use the bio->bi_bdev ? Err, since commit
> > 74d46992e0d9d, I mean bio->bi_disk to get the start sector?
> >
> > You should be able to get it from:
> >
> > struct hd_struct *part = disk_get_part(bio->bi_disk, bio->bi_partno);
> > part->start_sect;
> > disk_put_part(part);
> >
> > or:
> >
> > struct block_device *bdev = bdget_disk(bio->bi_disk, bio->bi_partno);
> > get_start_sect(fc->dev->bdev);
> > bdput(bdev);
>
> I am afraid this does not work. The original bio disk is of course /dev/dm-xx so
> not the partition (partno == 0), and the mapped bio passed as argument to the
> remap zone function (clone of the orig bio) is pointing to the entire underlying
> disk, not the partition disk used in dmsetup. bi_partno is 0 for both BIOs.
> Which seems weird, __bio_clone_fast() does copy the disk and part number as is.
> The disk is of course correctly changed from the orig dm disk to the actual
> physical disk in the clone, but the partition number stays the same. In the end,
> only the target has the correct bdev (disk+partno) information it seems.
OK, that is a bug that must to be found then.
> It looks like the partno gets lost, which does not seem correct. I must be
> missing something, but I fail to see what it is. Any suggestion ?
Not at the moment but I'll have a closer look early next week.
Thanks,
Mike
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: dm: Fix report zone remapping
Date: Fri, 5 Oct 2018 23:49:47 -0400 [thread overview]
Message-ID: <20181006034946.GA7891@redhat.com> (raw)
In-Reply-To: <BN3PR0401MB1640B2763051334D011B0111E7E40@BN3PR0401MB1640.namprd04.prod.outlook.com>
On Fri, Oct 05 2018 at 9:24pm -0400,
Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> Mike,
>
> On 2018/10/06 3:29, Mike Snitzer wrote:
> > On Fri, Oct 05 2018 at 6:34am -0400,
> > Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >
> >> If dm-linear or dm-flakey have targets on top of a partition of a zoned
> >> block device, remapping of the start sector and write pointer position
> >> of the zones reported by a report zones BIO must be modified to not
> >> only account for the target table entry mapping, but also to account
> >> for the partition first sector. This start sector must be substracted
> >> to the start sector of all zones reported. The write pointer position
> >> of sequential zones must also be reduced by this offset.
> >>
> >> Since there is no easy way to access the underlying bdev of the target
> >> table entry from the dm_target or dm_target_io pointers, modify the
> >> interface of the function dm_remap_zone_report() to allow a target to
> >> pass the partition block device starting sector (offset).
> >>
> >> Fixes: 10999307c14e ("dm: introduce dm_remap_zone_report()")
> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >> Cc: <stable@vger.kernel.org>
> >
> > [dropping the actual stable cc from the mail, please don't cc stable in
> > the mail header, could be that git-send-email just pulled it in but...]
>
> My apologies about that. It was indeed git-send-email. Will fix that.
>
> > This needs a different fix. There should be absolutely no need to pass
> > in a start offset for a device that is already supposed to be described
> > within the 'struct bio' passed to dm_remap_zone_report().
> >
> > Why can't you just use the bio->bi_bdev ? Err, since commit
> > 74d46992e0d9d, I mean bio->bi_disk to get the start sector?
> >
> > You should be able to get it from:
> >
> > struct hd_struct *part = disk_get_part(bio->bi_disk, bio->bi_partno);
> > part->start_sect;
> > disk_put_part(part);
> >
> > or:
> >
> > struct block_device *bdev = bdget_disk(bio->bi_disk, bio->bi_partno);
> > get_start_sect(fc->dev->bdev);
> > bdput(bdev);
>
> I am afraid this does not work. The original bio disk is of course /dev/dm-xx so
> not the partition (partno == 0), and the mapped bio passed as argument to the
> remap zone function (clone of the orig bio) is pointing to the entire underlying
> disk, not the partition disk used in dmsetup. bi_partno is 0 for both BIOs.
> Which seems weird, __bio_clone_fast() does copy the disk and part number as is.
> The disk is of course correctly changed from the orig dm disk to the actual
> physical disk in the clone, but the partition number stays the same. In the end,
> only the target has the correct bdev (disk+partno) information it seems.
OK, that is a bug that must to be found then.
> It looks like the partno gets lost, which does not seem correct. I must be
> missing something, but I fail to see what it is. Any suggestion ?
Not at the moment but I'll have a closer look early next week.
Thanks,
Mike
next prev parent reply other threads:[~2018-10-06 3:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 10:34 [PATCH] dm: Fix report zone remapping Damien Le Moal
2018-10-05 18:29 ` Mike Snitzer
2018-10-05 18:29 ` Mike Snitzer
2018-10-06 1:24 ` Damien Le Moal
2018-10-06 1:24 ` Damien Le Moal
2018-10-06 3:49 ` Mike Snitzer [this message]
2018-10-06 3:49 ` Mike Snitzer
2018-10-06 4:03 ` Damien Le Moal
2018-10-06 4:03 ` Damien Le Moal
2018-10-06 5:32 ` Mike Snitzer
2018-10-06 5:32 ` Mike Snitzer
2018-10-06 7:37 ` Damien Le Moal
2018-10-06 7:37 ` Damien Le Moal
2018-10-08 16:25 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181006034946.GA7891@redhat.com \
--to=snitzer@redhat.com \
--cc=Damien.LeMoal@wdc.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.