[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200108150447.GC10975@lst.de>
Date: Wed, 8 Jan 2020 16:04:47 +0100
From: "hch@....de" <hch@....de>
To: "Singh, Balbir" <sblbir@...zon.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Chaitanya.Kulkarni@....com" <Chaitanya.Kulkarni@....com>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"hch@....de" <hch@....de>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"mst@...hat.com" <mst@...hat.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"Sangaraju, Someswarudu" <ssomesh@...zon.com>
Subject: Re: [resend v1 4/5] drivers/nvme/host/core.c: Convert to use
disk_set_capacity
On Mon, Jan 06, 2020 at 12:46:26AM +0000, Singh, Balbir wrote:
> On Sat, 2020-01-04 at 22:27 +0000, Chaitanya Kulkarni wrote:
> > Quick question here if user executes nvme ns-rescan /dev/nvme1
> > will following code result in triggering uevent(s) for
> > the namespace(s( for which there is no change in the size ?
> >
> > If so is that an expected behavior ?
> >
>
> My old code had a check to see if old_capacity != new_capacity as well.
> I can redo those bits if needed.
>
> The expected behaviour is not clear, but the functionality is not broken, user
> space should be able to deal with a resize event where the previous capacity
> == new capacity IMHO.
I think it makes sense to not bother with a notification unless there
is an actual change.
Powered by blists - more mailing lists