Re: [Scst-devel] Device creation in vdisk_blockio device handler

[Кирилл Т. <kir...@gm...>]

Hi Vlad,

I suggest following generic approach for active/passive configuration
through addition of attribute 'active' to vdisk_blockio devices:
1. Block disks are opening while activating vdisk_blockio devices and are
closing while deactivating.
2. By default attribute 'active' is set to one and block disks are opening
during creation vdisk_blockio devices.
3. For work with DRBD and another active/passive configuration attribute
'active' is set to zero before creation vdisk_blockio device on passive
node.
4. blockio_on_alua_state_change_start deactivates vdisk_blockio device.
5. blockio_on_alua_state_change_finish activates vdisk_blockio device for
alua states SCST_TG_STATE_OPTIMIZED/SCST_TG_STATE_NONOPTIMIZED.

--
Regards,
Kirill Tyushev

2016-12-08 10:36 GMT+03:00 Consus <co...@gm...>:

> On 19:26 Wed 07 Dec, Vladislav Bolkhovitin wrote:
> > Кирилл, Consus,
> >
> > Before proceed further, I would like that we all together consider full
> picture,
> > including interaction with other components (replication engine, cluster
> manager, etc.)
> > and figure out the good generic overall approach, hence, SCST interface.
> Adding new
> > attributes and return code handlers is easy, but messy, if done without
> proper planning.
> >
> > So, please go ahead and tell us how you see it. I currently have only
> DRBD visibility.
> >
> > Don't forget, that there are explicit and implicit ALUA state changes,
> which should be
> > better handled uniformly.
> >
> > Another note is that we already have it done for DRBD, so better to
> reuse this
> > infrastructure.
> >
> > Thanks,
> > Vlad
>
> Well... The idea is simple -- the block device I use exists only on one
> node of my A/P cluster at a time. On passive node there is no block
> device at all so SCST cannot open it. DRBD, on the contrary, tends to
> create a device node that cannot be opened, but instead of ENOENT open
> returns ENOMEDIUM so your code deals with it. The only difference
> between my LVM-based block device and DRBD is that DRBD creates a device
> node (not very usable one though) and LVM creates nothing because of the
> way it works.
>
> Honestly, I don't like this "treat ENOENT different because we set some
> flag" approach, but there is nothing else I can think of right now.
>