[stgt] persistent reservations through power loss

[Lee Duncan]

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.

> 
> 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