Linux-NVME Archive on lore.kernel.org
 help / color / Atom feed
* [RFC][PATCH] nvme/core: Notify udev about capacity change
@ 2019-11-29  0:27 Balbir Singh
  2019-11-29  8:24 ` Christoph Hellwig
  0 siblings, 1 reply; 8+ messages in thread
From: Balbir Singh @ 2019-11-29  0:27 UTC (permalink / raw)
  To: linux-nvme
  Cc: Sagi Grimberg, Jens Axboe, Someswarudu Sangaraju, Keith Busch,
	Balbir Singh, Christoph Hellwig

From: Someswarudu Sangaraju <ssomesh@amazon.com>

NVME capacity can change asynchronously via NVME_AER_NOTICE_NS_CHANGED
The current stack does the right thing and resizes the disk via
set_capacity() called from nvme_update_disk_info(). This patch adds
a user space notification via uevent to let udev know that a resize
occurred if the capacity changes.

Signed-off-by: Someswarudu Sangaraju <ssomesh@amazon.com>
[Balbir - send the notification only on capacity change and wrote the
changelog]
Signed-off-by: Balbir Singh <sblbir@amazon.com>
---
 drivers/nvme/host/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index dfe37a525f3a..a413aee3107d 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1757,6 +1757,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
 		struct nvme_ns *ns, struct nvme_id_ns *id)
 {
 	sector_t capacity = nvme_lba_to_sect(ns, le64_to_cpu(id->nsze));
+	sector_t old_capacity = get_capacity(disk);
 	unsigned short bs = 1 << ns->lba_shift;
 	u32 atomic_bs, phys_bs, io_opt;
 
@@ -1807,6 +1808,11 @@ static void nvme_update_disk_info(struct gendisk *disk,
 		capacity = 0;
 
 	set_capacity(disk, capacity);
+	if (old_capacity != capacity) {
+		char *envp[] = { "RESIZE=1", NULL };
+
+		kobject_uevent_env(&disk_to_dev(disk)->kobj, KOBJ_CHANGE, envp);
+	}
 
 	nvme_config_discard(disk, ns);
 	nvme_config_write_zeroes(disk, ns);
-- 
2.16.5


_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-11-29  0:27 [RFC][PATCH] nvme/core: Notify udev about capacity change Balbir Singh
@ 2019-11-29  8:24 ` Christoph Hellwig
  2019-12-02 23:35   ` Singh, Balbir
  0 siblings, 1 reply; 8+ messages in thread
From: Christoph Hellwig @ 2019-11-29  8:24 UTC (permalink / raw)
  To: Balbir Singh
  Cc: Sagi Grimberg, linux-nvme, Jens Axboe, Someswarudu Sangaraju,
	Keith Busch, Christoph Hellwig

I don't think this makes sense, and they way it has been done in
virtio_blk and xen-blkfront is an utter hack.  Please first add a
properly documented block helper, and then make sure it doesn't send the
even for the first call that moves from a 0 capacity.  SCSI also will
need updating to use the helper.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-11-29  8:24 ` Christoph Hellwig
@ 2019-12-02 23:35   ` Singh, Balbir
  2019-12-03  6:54     ` hch
  0 siblings, 1 reply; 8+ messages in thread
From: Singh, Balbir @ 2019-12-02 23:35 UTC (permalink / raw)
  To: hch; +Cc: kbusch, axboe, sagi, linux-nvme, Sangaraju, Someswarudu

On Fri, 2019-11-29 at 09:24 +0100, Christoph Hellwig wrote:
> I don't think this makes sense, and they way it has been done in
> virtio_blk and xen-blkfront is an utter hack.  Please first add a
> properly documented block helper, and then make sure it doesn't send the
> even for the first call that moves from a 0 capacity.  SCSI also will
> need updating to use the helper.

Makes sense, I am wondering if I should refactor
set_capacity to __set_capacity and have set_capacity do notifcations
for

oldsize vs newsize where oldsize is not 0

Balbir Singh.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-12-02 23:35   ` Singh, Balbir
@ 2019-12-03  6:54     ` hch
  2019-12-03  7:26       ` Chaitanya Kulkarni
  0 siblings, 1 reply; 8+ messages in thread
From: hch @ 2019-12-03  6:54 UTC (permalink / raw)
  To: Singh, Balbir
  Cc: sagi, linux-nvme, axboe, Sangaraju, Someswarudu, kbusch, hch

On Mon, Dec 02, 2019 at 11:35:47PM +0000, Singh, Balbir wrote:
> On Fri, 2019-11-29 at 09:24 +0100, Christoph Hellwig wrote:
> > I don't think this makes sense, and they way it has been done in
> > virtio_blk and xen-blkfront is an utter hack.  Please first add a
> > properly documented block helper, and then make sure it doesn't send the
> > even for the first call that moves from a 0 capacity.  SCSI also will
> > need updating to use the helper.
> 
> Makes sense, I am wondering if I should refactor
> set_capacity to __set_capacity and have set_capacity do notifcations
> for
> 
> oldsize vs newsize where oldsize is not 0

I pretty much hate the set_capacity name to start with, so what about
a more descriptive name for new the helper?  blk_set_capacity?

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-12-03  6:54     ` hch
@ 2019-12-03  7:26       ` Chaitanya Kulkarni
  2019-12-03  7:34         ` hch
  0 siblings, 1 reply; 8+ messages in thread
From: Chaitanya Kulkarni @ 2019-12-03  7:26 UTC (permalink / raw)
  To: hch, Singh, Balbir
  Cc: axboe, Sangaraju, Someswarudu, kbusch, sagi, linux-nvme

On 12/02/2019 10:54 PM, hch@lst.de wrote:
> I pretty much hate the set_capacity name to start with, so what about
> a more descriptive name for new the helper?  blk_set_capacity?

Do we also need a blk_mq_ops or appropriate block layer callback
capacity change function, so that file systems can register
a callback function to take an appropriate action, e.g.
rebuilding the metadata with new size ?

If this make sense I'll be happy to take a look.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-12-03  7:26       ` Chaitanya Kulkarni
@ 2019-12-03  7:34         ` hch
  2019-12-03 12:43           ` Johannes Thumshirn
  0 siblings, 1 reply; 8+ messages in thread
From: hch @ 2019-12-03  7:34 UTC (permalink / raw)
  To: Chaitanya Kulkarni
  Cc: sagi, linux-nvme, axboe, Sangaraju, Someswarudu, kbusch, Singh,
	Balbir, hch

On Tue, Dec 03, 2019 at 07:26:03AM +0000, Chaitanya Kulkarni wrote:
> On 12/02/2019 10:54 PM, hch@lst.de wrote:
> > I pretty much hate the set_capacity name to start with, so what about
> > a more descriptive name for new the helper?  blk_set_capacity?
> 
> Do we also need a blk_mq_ops or appropriate block layer callback
> capacity change function, so that file systems can register
> a callback function to take an appropriate action, e.g.
> rebuilding the metadata with new size ?
> 
> If this make sense I'll be happy to take a look.

Well, and op isn't going to help with file system notifications as
that goes the other way around.  We'd probably need some way how
file systems can register a new callback into the existing block
device events framework that is used for media changes.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-12-03  7:34         ` hch
@ 2019-12-03 12:43           ` Johannes Thumshirn
  2019-12-03 12:52             ` hch
  0 siblings, 1 reply; 8+ messages in thread
From: Johannes Thumshirn @ 2019-12-03 12:43 UTC (permalink / raw)
  To: hch
  Cc: sagi, Chaitanya Kulkarni, linux-nvme, axboe, Sangaraju,
	Someswarudu, kbusch, Singh, Balbir

On Tue, Dec 03, 2019 at 08:34:47AM +0100, hch@lst.de wrote:
> On Tue, Dec 03, 2019 at 07:26:03AM +0000, Chaitanya Kulkarni wrote:
> > On 12/02/2019 10:54 PM, hch@lst.de wrote:
> > > I pretty much hate the set_capacity name to start with, so what about
> > > a more descriptive name for new the helper?  blk_set_capacity?
> > 
> > Do we also need a blk_mq_ops or appropriate block layer callback
> > capacity change function, so that file systems can register
> > a callback function to take an appropriate action, e.g.
> > rebuilding the metadata with new size ?
> > 
> > If this make sense I'll be happy to take a look.
> 
> Well, and op isn't going to help with file system notifications as
> that goes the other way around.  We'd probably need some way how
> file systems can register a new callback into the existing block
> device events framework that is used for media changes.

I had this on my TODO List but one thing stopped my endeavors, having a
"notifier" for resize is easy when we only grow the block-device, but what
should the FS do when we shrink it?

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [RFC][PATCH] nvme/core: Notify udev about capacity change
  2019-12-03 12:43           ` Johannes Thumshirn
@ 2019-12-03 12:52             ` hch
  0 siblings, 0 replies; 8+ messages in thread
From: hch @ 2019-12-03 12:52 UTC (permalink / raw)
  To: Johannes Thumshirn
  Cc: sagi, Chaitanya Kulkarni, linux-nvme, axboe, Sangaraju,
	Someswarudu, kbusch, Singh, Balbir, hch

On Tue, Dec 03, 2019 at 01:43:51PM +0100, Johannes Thumshirn wrote:
> I had this on my TODO List but one thing stopped my endeavors, having a
> "notifier" for resize is easy when we only grow the block-device, but what
> should the FS do when we shrink it?

Assuming this is a "normal" fs and not something fancy with built
in redundancy - shut the file system down and stop any new access to
it as that would just make things worse.

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-29  0:27 [RFC][PATCH] nvme/core: Notify udev about capacity change Balbir Singh
2019-11-29  8:24 ` Christoph Hellwig
2019-12-02 23:35   ` Singh, Balbir
2019-12-03  6:54     ` hch
2019-12-03  7:26       ` Chaitanya Kulkarni
2019-12-03  7:34         ` hch
2019-12-03 12:43           ` Johannes Thumshirn
2019-12-03 12:52             ` hch

Linux-NVME Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-nvme/0 linux-nvme/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nvme linux-nvme/ https://lore.kernel.org/linux-nvme \
		linux-nvme@lists.infradead.org
	public-inbox-index linux-nvme

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-nvme


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git