Neil Brown <neilb@xxxxxxx> wrote:
> On Monday April 20, Mario.Holbe@xxxxxxxxxxxxx wrote:
>> existing bitmapped device. When the full-sync of the new component is
>> finished, the bitmap on the new component does usually show still lots
>> of dirty bits (sometimes only a few %, sometimes up to 95%) while the
> I think that problem is fixed by
> commit 355a43e641b948a7b755cb4c2466ec548d5b495f
> which is in 2.6.29.
.2 probably :)
While looking at commit 355a43e641b948a7b755cb4c2466ec548d5b495f I'm not
sure, if this could raise a race condition: the comment in
next_active_rdev() states:
* As devices are only added or removed when raid_disk is < 0 and
* nr_pending is 0 and In_sync is clear, the entries we return will
* still be in the same position on the list when we re-enter
* list_for_each_continue_rcu.
but commit 355a43e641b948a7b755cb4c2466ec548d5b495f does exactly remove
the In_sync test. If the comment is true, the removal of the test
probably opens a window for a race condition.
regards
Mario
--
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
[Holger Veit in doc]
--
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
