Re: [PATCH 01/33] TCMU PR: first commit to implement TCMU PR

From: Zhu Lingshan <lszhu@suse.com>
To: target-devel@vger.kernel.org
Subject: Re: [PATCH 01/33] TCMU PR: first commit to implement TCMU PR
Date: Sun, 17 Jun 2018 04:40:56 +0000	[thread overview]
Message-ID: <31ba1176-9b8e-cd9d-c025-b91433a79489@suse.com> (raw)
In-Reply-To: <20180615182342.6239-1-lszhu@suse.com>


On 2018/6/17 3:20, Mike Christie wrote:
> Adding Bodo who is working on a alternative approach.
>
> On 06/16/2018 12:22 AM, Christoph Hellwig wrote:
>> On Sat, Jun 16, 2018 at 02:23:10AM +0800, Zhu Lingshan wrote:
>>> These commits and the following intend to implement Persistent
>>> Reservation operations for TCMU devices.
>> Err, hell no.
>>
>> If you are that tightly integrated with the target code that you can
>> implement persistent reservation you need to use kernel code.
>> Everything else just creates a way too complex interface.
> Hey Christoph,
>
> Just wanted to make sure I understood this comment. In Lingshan's
> patches I think he was going to end up calling out to
> userspace/tcmu-runner and there he was going to make ceph calls which
> basically translate PGR operations to ceph requests. Are you saying we
> should just add some kernel module that makes the ceph calls? This would
> then avoid the mess of having the split PGR processing design in this
> patchset?
Hello Mike and Christoph´╝î
Thanks Mike's comment inspired me, if I understand this correctly, it is 
suggested to implement this whole solution in kernel, avoid
 ┬ásplitting PRG handling in both kernel and userspace, make it not that 
complex. I can try to implement this by sending OSD requests
from kernel side, then we don't need tcmu-runner supporting is, no need 
to use netlink to exchange information with userspace, pure kernel code, 
seems
much more simple. Do you think this may be better?

Thanks,
BR
Zhu Lingshan
>
>
> Also just to make it a little more fun :) There is another person
> working on a completely different design.
>
> Bodo's design is for tcmu only and allows userspace to just handle
> everything. PGR commands and related checks for conflicts are all
> handled in the userspace daemon that is receiving commands from the
> target_core_user kernel module.
>
> The one hiccup is this design requires a change where the I_T Nexus info
> is passed to userspace so it can handle certain PGR registration
> commands correction and also for each command check if a nexus has been
> registered and what reservation there is for it. We could:
>
> 	1. Just pass that info to userspace in each tcmu request.
>
> 	2. Do something like the old kernel tgt code did where when a I_T nexus
> was established in the kernel it sent an event to userspace. Each SCSI
> command passed to userspace had some tag that allowed userspace to match
> the tag with the I_T Nexus.
>

--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html