On Fri, 2018-06-15 at 13:45 +0200, Dominik Csapak wrote:
> > > 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
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
On Wed, 2018-06-13 at 09:31 +0200, Dominik Csapak wrote:
> hi, thanks for the patches
>
> i looked briefly over them (and will dive deeper into the code in
> the
> following days) and played a little around
>
> here an initial review of what i saw/found
>
> nitpicks:
>
> you used the wrong
hi, thanks for the patches
i looked briefly over them (and will dive deeper into the code in the
following days) and played a little around
here an initial review of what i saw/found
nitpicks:
you used the wrong git repository in the subject (container vs storage),
not really important,
introducing LIO/targetcli support allowing to use recent linux
distributions as iSCSI targets for ZFS volumes.
In order for this to work, two preconditions have to be met:
#1 the portal has to be set up correctly using targetcli
#2 the initiator has to be authorized to connect to the target
