[stgt] persistent reservations through power loss

[Alexander Gordeev]

В Tue, 24 Sep 2013 10:55:39 -0700
ronnie sahlberg <ronniesahlberg at gmail.com> пишет:

> On Tue, Sep 24, 2013 at 10:13 AM, Lee Duncan <lduncan at suse.com> wrote:
> > On 09/18/2013 08:41 AM, Alexander Gordeev wrote:
> >> Hi!
> >>
> >> I'd like to add correct handling of APTPL bit in PR OUT commands. I
> >> have the following plan:
> >> 1. create a new parameter ('pr_storage' ?) for target/LUN where tgtd
> >> should store registrations and reservations according to the SCSI spec
> >> 2. tgtd should read this storage LUN creation and populate lists of
> >> registrations and reservations and save the fd in the struct scsi_lu
> >> 3. adjust capabilities: return 1 for APTPL if the parameter is set for
> >> a LUN
> >> 4. when tgtd receives PR OUT command with APTPL set, it should
> >> asynchronously write changes to the store
> >
> > I'm worried about the obvious race condition potential if you write this
> > information asynchronously. What if this asynchronous write fails? What
> > if the storage containing this data is lost or goes offline?
> >
> > I believe you need your backing store writes to be synchronous if you
> > want persistence to work correctly.
> 
> Good points.
> But since changing the PR status should not be all that frequent,
> he could write this as an extended attribute and then immediately
> fdatasync() it before responding back to the initiator ?

This is a very interesting idea, but probably not applicable generally.
This will work only when the backing store is a file on a filesystem,
which supports extended attributes (BTW this is not my case, we are
going to export block devices).
BTW I'm also curious: does LVM supports something like this? I mean
storing some arbitrary data in it's metadata.


> >> Are you interested in these changes? What do you think about the plan?
> >> Is there anything else I should do too?
> >> At the very least, other possible problems aside, I think you should at least wait for the
> >> I also have some questions regarding storage format and writing changes
> >> asynchronously.
> >>
> >> I'd like to do it in a way that minimizes fs metadata changes so it
> >> should have some fixed size if possible. Are there any limits on the
> >> number of sessions per LUN or registartions per LUN in tgtd?
> >
> > I would have to look at the SCSI standard, but I'm sure there as check
> > condition a target can return when it has no more memory (which is why
> > you normally limit the list of registrants).
> >
> >>
> >> I'm not really familiar with tgtd's event loop (yet). How should
> >> working with PR storage be implemented? I think of opening fds with
> >> O_NONBLOCK and then using tgt_event_* functions to add by callbacks and
> >> control event mask. But how should I defer the returning of PR OUT
> >> status code?
> >>
> >> Thanks in advance for any help!
> >>
> >
> > --
> > Lee Duncan
> > SUSE Labs
> > --
> > To unsubscribe from this list: send the line "unsubscribe stgt" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html



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