The commit message has been cut off. Here is the full message: getinfo_super1: when deciding whether the array is clean or dirty, compare sb->resync_offset against MaxSector and not against sb->size With RAID6 resyncing and subsequent drive failures, it is possible to reach the case, in which sb->resync_offset==sb->size. This happens when resync is aborted due to drive failures, and immediately a rebuild of a spare starts. In this case, mdadm was considered the array as clean, while kernel was considering the array as dirty. It is better for mdadm also to consider the array as dirty in this case. On Mon, Feb 6, 2012 at 1:25 PM, Alexander Lyakas <alex.bolshoy@xxxxxxxxx> wrote: > From c1bc75c72f62c6583f17caa2d02a09dc72fbac74 Mon Sep 17 00:00:00 2001 > From: Alex Lyakas <alex@xxxxxxxxxxxxxxxxx> > Date: Mon, 6 Feb 2012 13:24:15 +0200 > Subject: [PATCH] getinfo_super1: when deciding whether the array is clean or > dirty, compare sb->resync_offset against MaxSector and not > against sb->size > > With RAID6 resyncing and subsequent drive failures, it is possible to > reach the case, in which sb->resync_offset==sb->size. This happens > when resync is aborted due to drive failures, a > > diff --git a/super1.c b/super1.c > index 867aa58..c643bd3 100644 > --- a/super1.c > +++ b/super1.c > @@ -573,7 +573,7 @@ static void getinfo_super1(struct supertype *st, > struct mdinfo *info, char *map) > info->array.utime = __le64_to_cpu(sb->utime); > info->array.chunk_size = __le32_to_cpu(sb->chunksize)*512; > info->array.state = > - (__le64_to_cpu(sb->resync_offset) >= __le64_to_cpu(sb->size)) > + (__le64_to_cpu(sb->resync_offset) != MaxSector) > ? 1 : 0; > > info->data_offset = __le64_to_cpu(sb->data_offset); -- 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
