On Fri, Oct 28, 2016 at 03:59:41PM +1100, Neil Brown wrote: > > > mddev->curr_resync usually records where the current resync is up to, > but during the starting phase it has some "magic" values. > > 1 - means that the array is trying to start a resync, but has yielded > to another array which shares physical devices, and also needs to > start a resync > 2 - means the array is trying to start resync, but has found another > array which shares physical devices and has already started resync. > > 3 - means that resync has commensed, but it is possible that nothing > has actually been resynced yet. > > It is important that this value not be visible to user-space and > particularly that it doesn't get written to the metadata, as the > resync or recovery checkpoint. In part, this is because it may be > slightly higher than the correct value, though this is very rare. > In part, because it is not a multiple of 4K, and some devices only > support 4K aligned accesses. > > There are two places where this value is propagates into either > ->curr_resync_completed or ->recovery_cp or ->recovery_offset. > These currently avoid the propagation of values 1 and 3, but will > allow 3 to leak through. > > Change them to only propagate the value if it is > 3. > > As this can cause an array to fail, the patch is suitable for -stable. > > Cc: stable@xxxxxxxxxxxxxxx > Reported-by: Viswesh <viswesh.vichu@xxxxxxxxx> > Signed-off-by: NeilBrown <neilb@xxxxxxxx> Good catch, applied, thanks! -- 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
