Hi Yibin,
>>> - For reserve/query/preempt/clear, we should return success once an
>>> iteration returns successfully.
>> That's what the dm_grab_bdev_for_ioctl path does.
>
> If I understand correctly, dm_grab_bdev_for_ioctl() select a working path,
> and
> pr_*() uses that path to do the actually work.
>
> This works for reserve/query/preempt/clear, but it may not work for
> release.
You're right - if we had a path mapping change inbetween we might
have a problem with the unregister. That beeing said we have an even
worse problem if the path we registered on disappeared permanently,
so we'll probably need a slightly more complex loop than the one
we have right now.
> I meant the API that callers from above block layer can use - They can not
> call
> dm_pr_*() directly. So adding blkdev_pr_ops_{register/reserve/etc}() would
> be
> great.
Take a look at the pNFS SCSI layout driver under fs/nfs/blocklayout
which is the currently existing in-kernel user of the API, it just
calls the block device methods directly.
What additional work would you place in the ops? Also can you please
send me a link to your user of the API?
>
>>> 5. Support for multiple targets devices.
>>> An md device might have multiple targets. Current implementation only supports
>>> single target device.
>> That's because it is so far only intended for dm-multipath, which always
>> uses as single target. I'm not against multi-target support, but we'll
>> need a detailed explanation of the use case.
>
> OK. Fair enough. That's rather a "good-to-have" than a "must-have".
As said I'm fine with adding as an enhancement, especially if you submit
an in-kernel user for it, but a useful opensource application also
would be more than enough of a justification
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
