On 07/15/2015 01:56 PM, Christoph Hellwig wrote: > An array can't issue a reservation, the initiator needs to register > it. Right now the only way to do it is through SG_IO passthrough, > which is a best luck effort it I/O isn't also using SG_IO and can't > be properly supported because of that. > > However I will submit an in-kernel reservation API soon which will > allow us to have that sort of control. My current prototyp only allows > for all-path reservations as I couldn't come up with a use case for > per-path reservations, but if such a need should arise we can add it > and take that into account in the multipathing code. > Which was my reasoning as well. I would consider a per-path reservation in a multipath setup an error, as the current multipath code is not able to handle this. With the current code we will fail a path due to the reservation conflict error, but whatever happens next depends on the type of reservation and the used prioritizer/path checker. It can be everything from 'just working' to recurrent path drops to and I/O stall (as SET TARGET PORT GROUPS might return an reservation conflict, too, so we wouldn't be able to switch to a working path...) And implementing a per-path reservation in multipath is far from trivial, so I'd rather not attempt this. _Especially_ not as you're working on a in-kernel reservation code. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
