On 26.10.22 16:15, Kui Liu wrote:
-----Original Message-----
From: Alexander Atanasov <alexander.atana...@virtuozzo.com>
Date: Wednesday, 26 October 2022 at 5:14 PM
To: Kui Liu <kui....@acronis.com>, Konstantin Khorenko <khore...@virtuozzo.com>,
Alexey Kuznetsov <kuz...@acronis.com>
Cc: Devel <devel@openvz.org>
Subject: Re: [Devel] [PATCH RH9] dm-ploop: port the standby mode feature.
Hi,
On 21.10.22 16:28, Kui Liu wrote:
>
>
> -----Original Message-----
> From: Alexander Atanasov <alexander.atana...@virtuozzo.com>
> Date: Friday, 21 October 2022 at 7:35 PM
> To: Kui Liu <kui....@acronis.com>, Konstantin Khorenko
<khore...@virtuozzo.com>, Alexey Kuznetsov <kuz...@acronis.com>
> Cc: Devel <devel@openvz.org>
> Subject: Re: [Devel] [PATCH RH9] dm-ploop: port the standby mode feature.
>
> On 21.10.22 14:28, Kui Liu wrote:
> > > > Ok - for the user space there are two options:
> > > > 1. add an argument to enable at creation
time
> > > > 2. command standby_enable /if using the
enable it is possible to
> > > > implement a disable command too/.
> > > >
> > > > I prefer the second approach but let's hear
other opinions too.
> > > > And yes we can possibly do both but is there a
use case ?
> > > >
> > > > [LIU]: Since the static key is a global option, I
also think the second approach is better.
> > > > In case of nodes with vStorage + ploop + iSCSI
setup, we just need to enable the static
> > > > key early in system init or iSCSI service init. I
don't think it is necessary to implement both.
> > >
> > > You are right. It will need at least one ploop device
created to issue a
> > > device mapper command to enable standby. Would a
module parameter work?
> > >
> > > [LIU] Yes, I think it is better to make the static key a
module parameter.
> >
> > This rised a question - how and who will pass the module
parameter when
> > required ? How we will handle the existin users ? What do
you think ?
> >
> > [LIU]: Like add a conf file ploop.conf in /etc/modprobe.d or
lib/modeprobe.d? This conf file can be shipped with the release image, or installed
later. Are you referring to VZ7 as existing users? I saw you also made the changes
to VZ7, but I'm not sure whether it is necessary to backport these changes to VZ7.
>
> Yes, VZ7 users - there are issues related to it so trying to fix
them.
> the modprobe.d would do but do you have a package that can install
the
> conf tied to the iSCSI target, so it gets installed only if the
iSCSI is
> used ?
>
> [LIU]: Yes, we do build the our own SCST package, so we can install the
conf from there.
After discussion turns out module_param is not an option - package is
always installed so it will enable the key always which is not what we
want.
To solve this we can
struct static_key ploop_standby_check = STATIC_KEY_INIT_FALSE;
+EXPORT_SYMBOL(ploop_standby_check)
and the module can enable it at use or init time.
static int scst_vstor_pr_init(struct scst_device *dev, const char
*cl_dev_id)
looks like the place to enable the static key and set the _en flag on
the queue.
_en flag is a MUST static key is a SHOULD - where do you think is the
best place to implement them in the scst code?
[LIU]: This would introduce explicit dependency between SCST and ploop module,
which I feel is inappropriate .
Can we instead export the static key via a sysfs file, say
/sys/kernel/ploop/ploop_standby_check?
We can export it via sysfs or proc but who and how will enable it thru
there ?
--
Regards,
Alexander Atanasov
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
