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 th
Hi Yibin,
On Thu, Oct 13, 2016 at 07:16:13PM +0800, Yibin Wang wrote:
> BTW, did you mean using dm_pr::fail_early as the indication whether
> multipath_iterate_devices() should fail early upon failure? If that's the
> case,
> I can't see it is used anywhere except in dm_pr_register().
>
> Please
On 2016/10/13 17:19, Yibin Wang wrote:
Hi Christoph,
Thanks for your reply. Comments inline...
On 2016/10/9 23:16, Christoph Hellwig wrote:
..
- For regisetr, we should stop iteration on failure, and
followed by a
non-stopping unregister operation.
What do you mean with "non
Hi Christoph,
Thanks for your reply. Comments inline...
On 2016/10/9 23:16, Christoph Hellwig wrote:
Hi Yibin,
On Sun, Oct 09, 2016 at 01:12:41PM +, wangyibin wrote:
1. Improper dm_pr_ops implementation.
The dm_pr_ops functions, except register/unregister, all result in
infinite loop by r
Hello Christoph,
There are several issues with current PR implementation:
1. Improper dm_pr_ops implementation.
The dm_pr_ops functions, except register/unregister, all result in
infinite loop by recursively calling themselves, which will definitely cause
stack overflow. In fact, they should be i
Hi Yibin,
On Sun, Oct 09, 2016 at 01:12:41PM +, wangyibin wrote:
> 1. Improper dm_pr_ops implementation.
> The dm_pr_ops functions, except register/unregister, all result in
> infinite loop by recursively calling themselves, which will definitely cause
> stack overflow. In fact, they should be
On Thu, Sep 22, 2016 at 04:14:50PM +0800, jiangyiwen wrote:
> I briefly reviewed the PR API. If I understand correctly, a bunch of PR
> dedicated operations (pr_ops) are defined in block_device_operations, which
> includes register, reserve, release, preempt and clear operations. But among
> these
On 2016/9/21 23:04, Mike Snitzer wrote:
> On Wed, Sep 21 2016 at 5:14am -0400,
> jiangyiwen wrote:
>
>> Hi guys,
>>
>> I'm sorry if someone else has already asked the same question before, but
>> here's what we are facing with generic multipath.
>>
>> We were evaluating SCSI-3 PR and hit the fol
On Wed, Sep 21, 2016 at 11:04:27AM -0400, Mike Snitzer wrote:
> Which kernel are you using? Christoph (now cc'd) has introduced a new
> PR api. I merged a fix from him relatively recently (commit 9c72bad1f3
> "dm: call PR reserve/unreserve on each underlying device")
The PR API will handle this
On Wed, Sep 21 2016 at 5:14am -0400,
jiangyiwen wrote:
> Hi guys,
>
> I'm sorry if someone else has already asked the same question before, but
> here's what we are facing with generic multipath.
>
> We were evaluating SCSI-3 PR and hit the following issue:
>
> Our IPSAN has two controllers (
10 matches
Mail list logo
