Re: Bug in 2.6.16-rc6 RAID size reporting

[Neil Brown]

On Wednesday March 15, joshua.kugler@xxxxxxx wrote:
> In my quest to get some stability in my system with large RAID devices, I 
> installed mdadm 2.3.1 and compiled and installed 2.6.16-rc6.
> 
> Ran this command:
> 
> mdadm -C /dev/md1 --auto=yes -l raid1 -n 2 /dev/etherd/e0.0 /dev/etherd/e1.0
> 
> Those are AoE devices, by the way.
> 
> Started fine, syncing at 43000K/sec or so.  Came in this morning, 
> and /proc/mdstat had this to report:
> 
> Personalities : [raid1] 
> md1 : active raid1 etherd/e1.0[1] etherd/e0.0[0]
>       5469958900 blocks super 1.0 [2/2] [UU]
>       [==========================================================>]  resync 
> =292.8% (3440402688/1174991604) finish=785.8min speed=43043K/sec
> 
> You'll notice that it says 5469958900 blocks, but 3440402688/1174991604 done.  

Hmmm. there is sever bitrot in that code.  The following patch might
help.

> 
> if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery))
> 	max_blocks = mddev->resync_max_sectors >> 1;
> else
> 	max_blocks = mddev->size;
> 
> Should max_blocks be mddev->size even if it is resyncing?

Yes, you have to resync the entire array - all ->size of it...  maybe
you are misunderstanding one of the (probably undocumented)
variables..

NeilBrown



### Diffstat output
 ./drivers/md/md.c |   28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2006-03-14 17:40:12.000000000 +1100
+++ ./drivers/md/md.c	2006-03-16 15:08:18.000000000 +1100
@@ -4376,7 +4376,10 @@ static void status_unused(struct seq_fil
 
 static void status_resync(struct seq_file *seq, mddev_t * mddev)
 {
-	unsigned long max_blocks, resync, res, dt, db, rt;
+	sector_t max_blocks, resync, res;
+	unsigned long dt, db, rt;
+	int scale;
+	unsigned int per_milli;
 
 	resync = (mddev->curr_resync - atomic_read(&mddev->recovery_active))/2;
 
@@ -4392,9 +4395,22 @@ static void status_resync(struct seq_fil
 		MD_BUG();
 		return;
 	}
-	res = (resync/1024)*1000/(max_blocks/1024 + 1);
+	/* Pick 'scale' such that (resync>>scale)*1000 will fit
+	 * in a sector_t, and (max_blocks>>scale) will fit in a
+	 * u32, as those are the requirements for sector_div.
+	 * Thus 'scale' must be at least 10
+	 */
+	scale = 10;
+	if (sizeof(sector_t) > sizeof(unsigned long)) {
+		while ( max_blocks/2 > (1ULL<<(scale+32)))
+			scale++;
+	}
+	res = (resync>>scale)*1000;
+	sector_div(res, (u32)((max_blocks>>scale)+1));
+
+	per_milli = res;
 	{
-		int i, x = res/50, y = 20-x;
+		int i, x = per_milli/50, y = 20-x;
 		seq_printf(seq, "[");
 		for (i = 0; i < x; i++)
 			seq_printf(seq, "=");
@@ -4403,12 +4419,14 @@ static void status_resync(struct seq_fil
 			seq_printf(seq, ".");
 		seq_printf(seq, "] ");
 	}
-	seq_printf(seq, " %s =%3lu.%lu%% (%lu/%lu)",
+	seq_printf(seq, " %s =%3u.%u%% (%llu/%llu)",
 		   (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery)?
 		    "reshape" :
 		      (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) ?
 		       "resync" : "recovery")),
-		      res/10, res % 10, resync, max_blocks);
+		      per_milli/10, per_milli % 10,
+		   (unsigned long long) resync,
+		   (unsigned long long) max_blocks);
 
 	/*
 	 * We do not want to overflow, so the order of operands and
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/