[pve-devel] [PATCH container 0/2] Linux LIO/targetcli support

[Dominik Csapak]

>> during my initial tests, it worked (mostly) but i found some strange
>> behaviours:
>>
>> when we execute a zfs request not in a worker (e.g. a content
>> listing)
>> and then create a lun in a worker, only that worker, and no future
>> worker knows of it (because when we fork, we copy all data currently
>> in
>> variables)
>>
>> this seems due to the $SETTINGS variable which get filled whenever we
>> get info from the target
> 
> can you please elaborate what a "worker" is in PVE speech?

our daemons (pvedaemon, pveproxy) have a hard timeout for (synchronous) 
api calls (afair its 30 seconds), so for long running tasks
we do a 'fork_worker' which forks the process and generates a
task log entry

such a 'worker' copies the state of the forked process, including
the content of variables

> 
>> it seems this is a general problem also for the other zfs over iscsi
>> providers, has anyone who uses them (@mir?) the same problems?
>> how do you prevent/handle this?
>>
>> a possible solution i guess would be to prevent filling the
>> $SETTINGS variable when not in a worker, any other idea?
> 
> One of the things I found too about SETTINGS is that the other
> providers somehow seem to use it as a "cache", in order to reduce the
> amount of calls between the PVE and the target.

this cache is in general a good idea, because if we have an
api call that needs many infos in short time it makes it faster
e.g. an clone call of a vm with 10 disks:

* get infos about 10 disks
* create 10 disks
* copy 10 disks

in such a case, a cache can be useful

i do not know how costly the connections to a target really is, so i
cannot really say if this caching makes sense and we have to fix it,
or to drop it altogether

> 
> This has the dangerous drawback, that if some external process modifies
> the target (ie adds or removes another LUN), PVE will probably never
> pick up that change, because it relies on the assumption that the
> target is only controlled by the PVE. I have not fully investigated
> this though.

that is exactly the problem, but also happens within pve
(due to the worker mechanic)

> 
> Originally I always repopulated the SETTINGS variable before running
> any "LUN command", but after looking at the other implementations, I
> decided to do it as they do it.

if the time to get the information is not too high, i would in general
prefer your initial approach. but since the other implementations
also do this, i originally asked @Michael (or mir; the initial author
of this plugin) this

> 
> So the "easy" fix for this would probably be to revert that and to
> repopulate the SETTINGS hash for each call.

another option would be to have a 'clear cache' sub and
if we executed a command *not* in a worker we call it after
the 'lun_command' call in ZFSPlugin.pm

or a 'cache' parameter which indicates the use of cache,
which we can the use in a worker

any other opinions?