From: Brian Auld <bauld@lefthandnetworks.com>
To: linux-scsi@vger.kernel.org
Subject: Question about the use of PERSISTENT RESERVATION IN/OUT
Date: Thu, 01 Apr 2004 13:41:06 -0700 [thread overview]
Message-ID: <406C7E62.7020109@lefthandnetworks.com> (raw)
I was able to acquire some level of understanding of the use of "persistent
reservation in/out" commands after having read some SCSI specs and browsing
this mailing list's archives. I have made some presumptions and wanted
to run
them by this list to make sure I wasn't too far out in left field.
I'm designing a linux-based application that is going to use LUNs for
storage
from a backend FC SAN. It's not very sexy, but there is a one to one
relationship for i) boxes running my appl and ii) LUNs. One of the
requirements
that has been imposed on the appl is that once a given backend LUN has been
assigned to my application, any other physical entity (i.e. a different
initiator on a different box, which could be running my appl) is to be
prevented from accessing this LUN using some kind of protection mechanism.
Once a LUN is assigned to a specific box running my appl, this protection
should exist until I explicitly deassign this LUN in my user interface. In
other words, the protection should persist across host reboots and target
reset/reboots.
I have made the following assumptions and decisions about how this will be
handled:
1) As I understand it, there is no reserve/release (persistent or old)
mechanism in the scsi subsystem itself.
2) WRT (1), there are however 2 mechanisms for sending pass-through commands
through the scsi subsystem directly to a target device: namely, (i) using an
sg device or (ii) sd ioctls.
3) What I would like to do is setup my application so the following
occurs when
a LUN is assigned/deassigned to my appl:
assigned:
-------------
In my appl, send an appropriate combination of PERSISTENT RESERVE
OUT(service
action: reserve ...) commands to effectivly lock this device so that any
initiator not included in the list I provide will be prevented from
accessing
my LUN. I would use the sg mechanism or sd ioctls to do this.
deassigned:
---------------
In my appl, send an appropriate combination of PERSISTENT RESERVE OUT
(service
action: release) commands to free up this LUN. Again, I would use sd ioctls
or the sg mechanism to do this.
Is this basic approach flawed? It would seem to be doable based on what
I have
read so far, but I don't know for sure.
Any feedback would be appreciated.
Thanks,
Brian
next reply other threads:[~2004-04-01 20:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 20:41 Brian Auld [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-01 21:06 Question about the use of PERSISTENT RESERVATION IN/OUT Brian Auld
[not found] <53CF1076699CD711B7DD0002A51363F102AD7F70@exw-ks.ks.lsil.com>
2004-04-01 22:20 ` Brian Auld
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=406C7E62.7020109@lefthandnetworks.com \
--to=bauld@lefthandnetworks.com \
--cc=linux-scsi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.