On Friday May 28, Mario.Holbe@xxxxxxxxxxxxxxxx wrote: > NeilBrown <neilb@xxxxxxxxxxxxxxx> wrote: > > This requires allocating a new pool of "r1bio" structures which a different > > number of bios, suspending IO, and swapping the new pool in place of the old. > > (and a few other related changes). > > Hmmm, I'm not really familiar with the md-code, but doesn't > do memory allocation at runtime re-introduce the 2.2. swap- > on-raid-problems? No. > Afair, they were due to swap out -> md driver allocates > something -> no ram -> swap out -> md driver allocates ... > This was not the problem. When the md driver allocated memory in the write-out path it always does it with a flag that say "don't trigger any write-out to while trying to satisfy this request". It also manages memory in such a way (using mempools) that if a memory request fails, it can just wait for some pending requests to complete and it is certain to get some memory soon. Further, the "allocation a new pool" mentioned above is not in the write-out path for raid1 so it has no bearing on these issues. It allocates a new pool quite separately for the normally running of raid1. If all the needed allocations succeed, it blocks further requests, swaps the new pool in place of the old and makes other changes to reshape the array, and the allows further requests to proceed. The problem in 2.2 was only during resync. Because of how buffers were managed, swap could write out to a block that we in the process of being re-synced, and the resync process would overwrite the new swap data. The buffer management is now completely different and this is not a problem. I hope this makes it a tiny bit clearer. NeilBrown - 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
