On Tue, Feb 21, 2017 at 8:05 AM, NeilBrown <neilb@xxxxxxxx> wrote:
> On Mon, Feb 20 2017, Ming Lei wrote:
>
>> On Thu, Feb 16, 2017 at 12:39 PM, NeilBrown <neilb@xxxxxxxx> wrote:
>>>
>>> +static void inc_pending(struct r1conf *conf, sector_t start_next_window,
>>> + sector_t bi_sector)
>>> +{
>>> + /* The current request requires multiple r1_bio, so
>>> + * we need to increment the pending count, and the corresponding
>>> + * window count.
>>> + */
>>> + spin_lock(&conf->resync_lock);
>>> + conf->nr_pending++;
>>
>> Just be curious, in current code 'nr_pending' is increased in wait_barrier(),
>> and looks this patch introduces inc_pending() to do that on each r10_bio, but
>> not see any change in wait_barrier(), so that means there might be issue in
>> current implementation about operating on this counter?
>
> Did you read the more detailed description in the previous raid10.c
> patch?
> This patch follows the same logic as that patch.
OK, I see the point now:
- for the 1st r1_bio, conf->nr_pending is increased in wait_barrier()
- for the others, conf->nr_pending is increased in inc_pending().
Also I have another question:
- before this patch, both number of requests in windows
are increased only for WRITE I/O(see wait_barrier()), and decreased
for both READ/WRITE in complete path(see allow_barrier())
- after this patch, except for the 1st r1_bio, number of requests in
windows are increased for both WRITE/READ I/O, and decreased
for both READ/WRITE too.
Could you explain a bit about this change?
Thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
