On Tue, Sep 24, 2013 at 10:13 AM, Lee Duncan <lduncan@xxxxxxxx> 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 ?
>
>>
>> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
