All of lore.kernel.org
 help / color / mirror / Atom feed
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 14:06:47 -0700	[thread overview]
Message-ID: <406C8467.5090903@lefthandnetworks.com> (raw)

Sorry for the initial staggered email.

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



             reply	other threads:[~2004-04-01 21:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-01 21:06 Brian Auld [this message]
     [not found] <53CF1076699CD711B7DD0002A51363F102AD7F70@exw-ks.ks.lsil.com>
2004-04-01 22:20 ` Question about the use of PERSISTENT RESERVATION IN/OUT Brian Auld
  -- strict thread matches above, loose matches on Subject: below --
2004-04-01 20:41 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=406C8467.5090903@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.