Re: [PATCH V2 2/2] nvmet: add per ns thread to generate AEN

From: Anthony Iliopoulos <ailiop@suse.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH V2 2/2] nvmet: add per ns thread to generate AEN
Date: Wed, 8 Apr 2020 19:08:20 +0200	[thread overview]
Message-ID: <20200408170820.GE1329@technoir> (raw)
In-Reply-To: <SN6PR04MB4973222BC905A09B9CA0E55586C00@SN6PR04MB4973.namprd04.prod.outlook.com>

On Wed, Apr 08, 2020 at 03:25:38PM +0000, Chaitanya Kulkarni wrote:
> On 04/08/2020 02:55 AM, Anthony Iliopoulos wrote:
> > So in the original design I had assumed that the burden of AEN
> > generation falls on userspace, given that the resizing of either a block
> > device or a file is something that userspace would initiate anyway. As
> > such, the same process could simply issue a nvme rescan ioctl to effect
> > the capacity changes (this is why in the original patch I had wired up
> > revalidate with identify).
> >
> > With the udev notification patchset in place one could trigger the
> > rescan for bdev-backed targets (e.g. do a nvme ns-rescan, or toggle
> > the existing nvmet ns enable configfs attr to induce the change). Some
> > revalidation actions will necessarily remain in userspace, e.g. in
> > blktests where loopback bdev is used, it requires a LOOP_SET_CAPACITY
> > ioctl to reflect the changes (losetup -c).
> >
> 
> > For file-backed targets, userspace may leverage inotify to achieve the
> > same. Otherwise a size change notifier would be required to trigger a
> > rescan (e.g. see fs/attr.c:notify_change()). The issue though here is
> > that there is no immediate way to associate a filp to a namespace, which
> > means that the handler would need to iterate all controllers and every
> > namespace to match it - not very nice, and probably isn't worth the
> > complexity.
> >
> 
> We need this for file back-end since it provides user flexibility about
> managing the ns.
> 
> I think we should at-least try global maintenance thread, if that didn't 
> work out we can always get back to the user-space solution.

Sure, but please note that this doesn't cover all use-cases, notably the
bdev-over-loopback example that I mentioned (truncate on the file that
backs loopback won't be reflected to its bdev w/o losetup -c, so the
maintenance thread will never pick up any change). Are there any
scenarios using non-loopback-based backing bdevs that admit resizing?

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