[SPDK] Re: is it possible to add a blacklist for the lvol module?

Hi, Tomek.

When I read this email, the meeting has started. If you'd like to
discuss this topic in next meeting, I will attend. If there is any
update in today's meeting, please let me know.
I agree that this feature is more suitable to be implemented on the
bdev layer. As you mentioned, the bdev_set_options RPC is registered
on SPDK_RPC_STARTUP. We may need to call it at run time. I think add
several 'examine' RPCs for this feature and register them on
SPDK_RPC_RUNTIME would be better. In my idea, we may add below RPCs:
(1) add_examine_blacklist: add a string pattern to the blacklist
(2) delete_examine_blacklist: delete a string pattern from the blacklist
(3) get_examine_blacklist: get the full blacklist
In the bdev_start function, we may check the bdev name, alias and uuid
against the blacklist, if the blacklist matches anything, the bdev
layer won't call the examine_disk function.
About how to "match" the bdev name, alias and uuid against the
blacklist, we may use the fnmatch function, thus we could support
wildcard, but the performance would be not very good. Instead of using
fnmatch, we may only check whether their prefix are matched, thus we
could store the blacklist as a prefix tree, the performance would be
better but it would be less powerful.

Please let me know whether you have any idea about it. If we could
point out an idea that the community would like to accept, I'd like to
implement it.

Best regards.

On Tue, Mar 31, 2020 at 4:58 AM Zawadzki, Tomasz
<tomasz.zawadzki(a)intel.com> wrote:
>
> Hi Peng Yu,
>
> Described scenario can occur for any bdev module that examines device being attached for metadata.
> Lvols, GPT, OCF, Raid5 (in future) and other custom ones.
> At this time there is no way to disable bdevs from examining the devices, without code changes.
>
> The proposed API would have to be on bdev layer, rather than any of the bdev module types.
> There is bdev subsystem options that could be changed (bdev_set_options() RPC).
>
> Another argument could be added that disables all examination, or as suggested blacklists examination on bdev name/alias/uuid.
> Drawback here is those options can be set only before subsystems are started (see framework_start_init()).
> So one cannot change mind after that.
>
> Bdev API could be extended with explicit 'examine' RPC to allow run-time examination for all or select bdev.
>
> Personally I'm not set on an approach, as examine functionality was supposed to be "straightforward" to use.
> Yet your example shows that in scenarios where SPDK is used on both ends of a connection (NVMe-oF/iSCSI/vhost),
> needs more thought.
>
> I'll add this topic to today's Community meeting agenda, please feel free to attend:
> https://spdk.io/community/
>
> Thanks,
> Tomek
>
> > -----Original Message-----
> > From: peng yu <yupeng0921(a)gmail.com>
> > Sent: Monday, March 30, 2020 8:56 PM
> > To: Storage Performance Development Kit <spdk(a)lists.01.org>
> > Subject: [SPDK] is it possible to add a blacklist for the lvol module?
> >
> > I have a below scenario:
> > A disk is controlled by SPDK APP A.
> > SPDK APP A exports the disk as a NVMEoF target SPDK APP B is a NVMEoF
> > initiator, it connects to that disk.
> > SPDk APP B creates a lvs and a lvol on the disk.
> > When I restart the APP A and APP B. The APP A will examine the disk and find
> > there is a lvs, and then the lvol module on APP A will claim this disk, then this
> > disk can't be exported over NVMEoF.
> >
> > Could we add a api to the lvol module? The api could add a dev name pattern
> > to a black list. When the lvol module examine a disk, it will check against the
> > black list, if a dev name matches the black list, it will ignore this device.
> >
> > Best regards.
> > _______________________________________________
> > SPDK mailing list -- spdk(a)lists.01.org
> > To unsubscribe send an email to spdk-leave(a)lists.01.org
> _______________________________________________
> SPDK mailing list -- spdk(a)lists.01.org
> To unsubscribe send an email to spdk-leave(a)lists.01.org