Re: Persistent Reservation API

[Hannes Reinecke <hare@suse.de>]

On 08/11/2015 11:30 AM, David Disseldorp wrote:
> Hi Christoph,
> 
> On Tue,  4 Aug 2015 09:11:05 +0200, Christoph Hellwig wrote:
> 
>> This series adds support for a simplified persistent reservation API
>> to the block layer.  The intent is that both in-kernel and userspace
>> consumers can use the API instead of having to hand craft SCSI or NVMe
>> command through the various pass through interfaces.  It also adds
>> DM support as getting reservations through dm-multipath is a major
>> pain with the current scheme.
>>
>> NVMe support currently isn't included as I don't have a multihost
>> NVMe setup to test on, but if I can find a volunteer to test it I'm
>> happy to write the code for it.
>>
>> The ioctl API is documented in Documentation/block/pr.txt, but to
>> fully understand the concept you'll have to read up the SPC spec,
>> PRs are too complicated that trying to rephrase them into different
>> terminology is just going to create confusion.
> 
> Do you have any thoughts on where SCSI-2 RESERVE/RELEASE should fit into
> this API, if at all? I.e. as a new enum pr_type members for
> pr_reserve()/pr_release(), as separate pr_ops hooks, etc?
> Similarly for PR_IN - IIUC, if LIO is to handle cluster wide PRs
> for Ceph rbd via the block layer, these will all need to be supported
> by block layer (and LIO backend) APIs.
> 
Just don't. Ignore SCSI-2 RESERVE/RELEASE.

To my knowledge there are _no_ 'real' SCSI-2 systems in the market
anymore; those which you might come across are 'fake' devices,
trying to emulate SCSI-2 for backwards compability despite being in
fact SCSI-3 devices.

I would vote for just ignoring them. Simply not worth the pain.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html