On Wed, Mar 09 2016, Dan Russell wrote:
> # mdadm --create /dev/md1 --assume-clean --level=6 --raid-devices=24
--chunk=64 --size=2929686528
22 * 2929686528 == 0xF01B45000
> # cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
> md1 : active (auto-read-only) raid6 dm-24[23] dm-23[22].....
> 17208463360 blocks super external:/md127/0 level 6, 64k chunk,....
17208463360 == 0x401B45000
So the size hasn't just be truncated to to some number of bits, but the
5th byte has changed from 0xF to 0x4.
That is very odd....
Ahhh.. I tried it myself, and used "mdadm -D" to look at the RAID6
array.
Used Dev Size : 782202880 (745.97 GiB 800.98 GB)
The requested per-device size was
2929686528 = 0xAE9F7800
the size given was
782202880 = 0x2E9F7800
so we lost the msbit there... Ahhhh.
diff --git a/super-ddf.c b/super-ddf.c
index faaf0a7ca9e0..0e00d17dd169 100644
--- a/super-ddf.c
+++ b/super-ddf.c
@@ -2688,10 +2688,10 @@ static int init_super_ddf_bvd(struct supertype *st,
free(vcl);
return 0;
}
- vc->blocks = cpu_to_be64(info->size * 2);
+ vc->blocks = cpu_to_be64(size * 2);
vc->array_blocks = cpu_to_be64(
calc_array_size(info->level, info->raid_disks, info->layout,
- info->chunk_size, info->size*2));
+ info->chunk_size, size*2));
memset(vc->pad1, 0xff, 8);
vc->spare_refs[0] = cpu_to_be32(0xffffffff);
vc->spare_refs[1] = cpu_to_be32(0xffffffff);
That was careless. "info" is a legacy structure which has a 32bit size
field. So a 64bit size if passed as a separate arg, but this function
used the wrong one :-(
I'll send off a patch.
Thanks for the report - and glad you could get at your data :-)
NeilBrown
Attachment:
signature.asc
Description: PGP signature
