From: Andy Grover <agrover@redhat.com>
To: Alex Elsayed <eternaleye@gmail.com>, target-devel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] target: Add a user-passthrough backstore
Date: Fri, 19 Sep 2014 17:35:29 -0700 [thread overview]
Message-ID: <541CCBD1.8050606@redhat.com> (raw)
In-Reply-To: <lvifie$emi$3@ger.gmane.org>
On 09/19/2014 04:51 PM, Alex Elsayed wrote:
>> Not sure I follow.. How does the proposed passthrough mode prevent
>> someone from emulating OSDs, media changers, optical disks or anything
>> else in userspace with TCMU..?
>>
>> The main thing that the above comments highlight is why attempting to
>> combine the existing in-kernel emulation with a userspace backend
>> providing it's own emulation can open up a number of problems with
>> mismatched state between the two.
>
> It doesn't prevent it, but it _does_ put it in the exact same place as PSCSI
> regarding the warnings on the wiki. It means that if someone wants to
> implement (say) the optical disc or OSD CDBs, they then lose out on ALUA &co
> unless they implement it themselves - which seems unnecessary and painful,
> since those should really be disjoint. In particular, an OSD backed by RADOS
> objects could be a very nice thing indeed, _and_ could really benefit from
> ALUA.
Some possible solutions:
1) The first time TCMU sees an opcode it passes it up and notes whether
it is handled or not. If it was handled then future cmds with that
opcode are passed up but not retried in the kernel. If it was not
handled then it and all future commands with that opcode are handled by
the kernel and not passed up.
2) Same as #1 but TCMU operates on SCSI spec granularity - e.g. handling
any SSC opcode means userspace must handle all SSC commands.
3) Like #2 but define opcode groupings that must all be implemented
together, independent of the specifications.
4) Have passthrough mode set at creation, but with more than two modes,
either grouped by SCSI spec or our own groupings.
5) Never pass up certain opcodes, like the ALUA ones or whatever.
Have a good weekend -- Andy
next prev parent reply other threads:[~2014-09-20 0:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 23:12 [PATCH 0/4] Userspace Passthrough backstore for LIO Andy Grover
2014-09-15 23:12 ` [PATCH 1/4] target: Remove unneeded check in sbc_parse_cdb Andy Grover
2014-09-15 23:12 ` [PATCH 2/4] uio: Export definition of struct uio_device Andy Grover
2014-09-15 23:12 ` [PATCH 3/4] target: Add documentation on the target userspace pass-through driver Andy Grover
2014-09-15 23:12 ` [PATCH 4/4] target: Add a user-passthrough backstore Andy Grover
2014-09-19 21:14 ` Nicholas A. Bellinger
[not found] ` <lvi81j$ud8$2@ger.gmane.org>
2014-09-19 23:39 ` Nicholas A. Bellinger
2014-09-19 23:51 ` Alex Elsayed
2014-09-20 0:35 ` Andy Grover [this message]
2014-09-22 20:58 ` Nicholas A. Bellinger
2014-09-22 21:00 ` Andy Grover
2014-09-22 21:03 ` Nicholas A. Bellinger
2014-09-22 20:36 ` Nicholas A. Bellinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541CCBD1.8050606@redhat.com \
--to=agrover@redhat.com \
--cc=eternaleye@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).