From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: "Jens Axboe" <axboe@kernel.dk>,
"Justin Sanders" <justin@coraid.com>,
"Josef Bacik" <josef@toxicpanda.com>,
"Ilya Dryomov" <idryomov@gmail.com>,
"Jack Wang" <jinpu.wang@cloud.ionos.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Minchan Kim" <minchan@kernel.org>,
"Mike Snitzer" <snitzer@redhat.com>, "Song Liu" <song@kernel.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
drbd-dev@lists.linbit.com, nbd@other.debian.org,
ceph-devel@vger.kernel.org, xen-devel@lists.xenproject.org,
linux-raid@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size
Date: Mon, 9 Nov 2020 10:25:22 +0100 [thread overview]
Message-ID: <e79f9a96-ef53-d6ea-f6e7-e141bdd2e2d2@suse.de> (raw)
In-Reply-To: <20201109085340.GB27483@lst.de>
On 11/9/20 9:53 AM, Christoph Hellwig wrote:
> On Mon, Nov 09, 2020 at 08:53:58AM +0100, Hannes Reinecke wrote:
>>> index 376096bfc54a83..4e86c9aafd88a7 100644
>>> --- a/drivers/nvme/host/core.c
>>> +++ b/drivers/nvme/host/core.c
>>> @@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
>>> capacity = 0;
[ .. ]
>> Originally nvme multipath would update/change the size of the multipath
>> device according to the underlying path devices.
>> With this patch the size of the multipath device will _not_ change if there
>> is a change on the underlying devices.
>
> Yes, it will. Take a close look at nvme_update_disk_info and how it is
> called.
>
Okay, then: What would be the correct way of handling a size update for
NVMe multipath?
Assuming we're getting an AEN for each path signalling the size change
(or a controller reset leading to a size change).
So if we're updating the size of the multipath device together with the
path device at the first AEN/reset we'll end up with the other paths
having a different size than the multipath device (and the path we've
just been updating).
- Do we care, or cross fingers and hope for the best?
- Shouldn't we detect the case where we won't get a size update for the
other paths, or, indeed, we have a genuine device size mismatch due to a
misconfiguration on the target?
IE shouldn't we have a flag 'size update pending' for the other paths,,
to take them out ouf use temporarily until the other AENs/resets have
been processed?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
WARNING: multiple messages have this Message-ID (diff)
From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: "Justin Sanders" <justin@coraid.com>,
"Mike Snitzer" <snitzer@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
linux-nvme@lists.infradead.org, "Song Liu" <song@kernel.org>,
dm-devel@redhat.com, drbd-dev@lists.linbit.com,
linux-scsi@vger.kernel.org, xen-devel@lists.xenproject.org,
"Ilya Dryomov" <idryomov@gmail.com>,
"Jack Wang" <jinpu.wang@cloud.ionos.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Josef Bacik" <josef@toxicpanda.com>,
nbd@other.debian.org, linux-raid@vger.kernel.org,
"Stefan Hajnoczi" <stefanha@redhat.com>,
ceph-devel@vger.kernel.org, "Jens Axboe" <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Minchan Kim" <minchan@kernel.org>,
linux-fsdevel@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size
Date: Mon, 9 Nov 2020 10:25:22 +0100 [thread overview]
Message-ID: <e79f9a96-ef53-d6ea-f6e7-e141bdd2e2d2@suse.de> (raw)
In-Reply-To: <20201109085340.GB27483@lst.de>
On 11/9/20 9:53 AM, Christoph Hellwig wrote:
> On Mon, Nov 09, 2020 at 08:53:58AM +0100, Hannes Reinecke wrote:
>>> index 376096bfc54a83..4e86c9aafd88a7 100644
>>> --- a/drivers/nvme/host/core.c
>>> +++ b/drivers/nvme/host/core.c
>>> @@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
>>> capacity = 0;
[ .. ]
>> Originally nvme multipath would update/change the size of the multipath
>> device according to the underlying path devices.
>> With this patch the size of the multipath device will _not_ change if there
>> is a change on the underlying devices.
>
> Yes, it will. Take a close look at nvme_update_disk_info and how it is
> called.
>
Okay, then: What would be the correct way of handling a size update for
NVMe multipath?
Assuming we're getting an AEN for each path signalling the size change
(or a controller reset leading to a size change).
So if we're updating the size of the multipath device together with the
path device at the first AEN/reset we'll end up with the other paths
having a different size than the multipath device (and the path we've
just been updating).
- Do we care, or cross fingers and hope for the best?
- Shouldn't we detect the case where we won't get a size update for the
other paths, or, indeed, we have a genuine device size mismatch due to a
misconfiguration on the target?
IE shouldn't we have a flag 'size update pending' for the other paths,,
to take them out ouf use temporarily until the other AENs/resets have
been processed?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: "Justin Sanders" <justin@coraid.com>,
"Mike Snitzer" <snitzer@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
linux-nvme@lists.infradead.org, "Song Liu" <song@kernel.org>,
dm-devel@redhat.com, linux-scsi@vger.kernel.org,
xen-devel@lists.xenproject.org,
"Ilya Dryomov" <idryomov@gmail.com>,
"Jack Wang" <jinpu.wang@cloud.ionos.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Josef Bacik" <josef@toxicpanda.com>,
nbd@other.debian.org, linux-raid@vger.kernel.org,
"Stefan Hajnoczi" <stefanha@redhat.com>,
drbd-dev@tron.linbit.com, ceph-devel@vger.kernel.org,
"Jens Axboe" <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Minchan Kim" <minchan@kernel.org>,
linux-fsdevel@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [dm-devel] [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size
Date: Mon, 9 Nov 2020 10:25:22 +0100 [thread overview]
Message-ID: <e79f9a96-ef53-d6ea-f6e7-e141bdd2e2d2@suse.de> (raw)
In-Reply-To: <20201109085340.GB27483@lst.de>
On 11/9/20 9:53 AM, Christoph Hellwig wrote:
> On Mon, Nov 09, 2020 at 08:53:58AM +0100, Hannes Reinecke wrote:
>>> index 376096bfc54a83..4e86c9aafd88a7 100644
>>> --- a/drivers/nvme/host/core.c
>>> +++ b/drivers/nvme/host/core.c
>>> @@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
>>> capacity = 0;
[ .. ]
>> Originally nvme multipath would update/change the size of the multipath
>> device according to the underlying path devices.
>> With this patch the size of the multipath device will _not_ change if there
>> is a change on the underlying devices.
>
> Yes, it will. Take a close look at nvme_update_disk_info and how it is
> called.
>
Okay, then: What would be the correct way of handling a size update for
NVMe multipath?
Assuming we're getting an AEN for each path signalling the size change
(or a controller reset leading to a size change).
So if we're updating the size of the multipath device together with the
path device at the first AEN/reset we'll end up with the other paths
having a different size than the multipath device (and the path we've
just been updating).
- Do we care, or cross fingers and hope for the best?
- Shouldn't we detect the case where we won't get a size update for the
other paths, or, indeed, we have a genuine device size mismatch due to a
misconfiguration on the target?
IE shouldn't we have a flag 'size update pending' for the other paths,,
to take them out ouf use temporarily until the other AENs/resets have
been processed?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2020-11-09 9:25 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 19:03 cleanup updating the size of block devices Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 01/24] block: remove the call to __invalidate_device in check_disk_size_change Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 02/24] loop: remove loop_set_size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-09 7:53 ` Hannes Reinecke
2020-11-09 7:53 ` [dm-devel] " Hannes Reinecke
2020-11-09 7:53 ` Hannes Reinecke
2020-11-09 8:53 ` Christoph Hellwig
2020-11-09 8:53 ` [dm-devel] " Christoph Hellwig
2020-11-09 8:53 ` Christoph Hellwig
2020-11-09 9:25 ` Hannes Reinecke [this message]
2020-11-09 9:25 ` [dm-devel] " Hannes Reinecke
2020-11-09 9:25 ` Hannes Reinecke
2020-11-09 23:28 ` Sagi Grimberg
2020-11-09 23:28 ` [dm-devel] " Sagi Grimberg
2020-11-09 23:28 ` Sagi Grimberg
2020-11-10 7:00 ` Hannes Reinecke
2020-11-10 7:00 ` [dm-devel] " Hannes Reinecke
2020-11-10 7:00 ` Hannes Reinecke
2020-11-06 19:03 ` [PATCH 04/24] sd: update the bdev size in sd_revalidate_disk Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-11 4:18 ` Martin K. Petersen
2020-11-11 4:18 ` [dm-devel] " Martin K. Petersen
2020-11-11 4:18 ` Martin K. Petersen
2020-11-06 19:03 ` [PATCH 05/24] block: remove the update_bdev parameter from set_capacity_revalidate_and_notify Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 06/24] block: add a return value to set_capacity_and_notify Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 07/24] nbd: remove the call to set_blocksize Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 08/24] nbd: move the task_recv check into nbd_size_update Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 09/24] nbd: refactor size updates Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 10/24] nbd: validate the block size in nbd_set_size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 11/24] nbd: use set_capacity_and_notify Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 12/24] aoe: don't call set_capacity from irq context Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 13/24] dm: use set_capacity_and_notify Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 14/24] pktcdvd: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 15/24] nvme: use set_capacity_and_notify in nvme_set_queue_dying Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 16/24] drbd: use set_capacity_and_notify Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 17/24] rbd: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-09 13:52 ` Ilya Dryomov
2020-11-09 13:52 ` [dm-devel] " Ilya Dryomov
2020-11-09 13:52 ` Ilya Dryomov
2020-11-06 19:03 ` [PATCH 18/24] rnbd: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-09 6:56 ` Jinpu Wang
2020-11-09 6:56 ` [dm-devel] " Jinpu Wang
2020-11-09 6:56 ` Jinpu Wang
2020-11-06 19:03 ` [PATCH 19/24] zram: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 20/24] dm-raid: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-06 19:03 ` [PATCH 21/24] md: " Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-07 0:32 ` Song Liu
2020-11-07 0:32 ` [dm-devel] " Song Liu
2020-11-07 0:32 ` Song Liu
2020-11-06 19:03 ` [PATCH 22/24] md: remove a spurious call to revalidate_disk_size in update_size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-07 0:39 ` Song Liu
2020-11-07 0:39 ` [dm-devel] " Song Liu
2020-11-07 0:39 ` Song Liu
2020-11-06 19:03 ` [PATCH 23/24] virtio-blk: remove a spurious call to revalidate_disk_size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-08 15:15 ` Paolo Bonzini
2020-11-08 15:15 ` [dm-devel] " Paolo Bonzini
2020-11-08 15:15 ` Paolo Bonzini
2020-11-09 10:22 ` Stefan Hajnoczi
2020-11-09 10:22 ` [dm-devel] " Stefan Hajnoczi
2020-11-09 10:22 ` Stefan Hajnoczi
2020-11-09 11:30 ` Michael S. Tsirkin
2020-11-09 11:30 ` [dm-devel] " Michael S. Tsirkin
2020-11-09 11:30 ` Michael S. Tsirkin
2020-11-06 19:03 ` [PATCH 24/24] block: unexport revalidate_disk_size Christoph Hellwig
2020-11-06 19:03 ` [dm-devel] " Christoph Hellwig
2020-11-06 19:03 ` Christoph Hellwig
2020-11-07 4:43 ` [dm-devel] " Jack Wang
2020-11-07 4:43 ` Jack Wang
2020-11-09 18:07 ` cleanup updating the size of block devices Josef Bacik
2020-11-09 18:07 ` [dm-devel] " Josef Bacik
2020-11-09 18:07 ` Josef Bacik
2020-11-11 8:26 cleanup updating the size of block devices v2 Christoph Hellwig
2020-11-11 8:26 ` [PATCH 03/24] nvme: let set_capacity_revalidate_and_notify update the bdev size Christoph Hellwig
2020-11-11 8:26 ` Christoph Hellwig
2020-11-11 13:06 ` Hannes Reinecke
2020-11-11 13:06 ` Hannes Reinecke
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=e79f9a96-ef53-d6ea-f6e7-e141bdd2e2d2@suse.de \
--to=hare@suse.de \
--cc=axboe@kernel.dk \
--cc=ceph-devel@vger.kernel.org \
--cc=dm-devel@redhat.com \
--cc=drbd-dev@lists.linbit.com \
--cc=hch@lst.de \
--cc=idryomov@gmail.com \
--cc=jasowang@redhat.com \
--cc=jinpu.wang@cloud.ionos.com \
--cc=josef@toxicpanda.com \
--cc=justin@coraid.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-raid@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=minchan@kernel.org \
--cc=mst@redhat.com \
--cc=nbd@other.debian.org \
--cc=pbonzini@redhat.com \
--cc=roger.pau@citrix.com \
--cc=snitzer@redhat.com \
--cc=song@kernel.org \
--cc=stefanha@redhat.com \
--cc=xen-devel@lists.xenproject.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.