On Tue, Feb 21, 2017 at 8:05 AM, NeilBrown [off-list ref] wrote:

On Mon, Feb 20 2017, Ming Lei wrote:

quoted

On Thu, Feb 16, 2017 at 12:39 PM, NeilBrown [off-list ref] wrote:

quoted

+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