Here's an updated, cleaned up version of my patch. Since the action is
superblock version-specific, it now indirects through super_types[] as other
version-specific parts of md.c do. At present it allows the rdev->size to be
updated through sysfs for metadata types 1.1 and 1.2, making all the correct
checks on the supplied value. It also supports growing rdev->size as large
as possible for the block device using echo "0" >/sys/block/mdX/md/rdY/size.

If you try to extend the size of 1.0 and 0.90 devices so that the data area
would overlap the superblock, rdev_size_store just returns EBUSY, the same
behaviour as previously. I'd like to support metadata types 0.90 and 1.0
too, relocating the superblock. I think it'd be sufficient to write a new
one at the end of the device then update rdev->sb_offset. I'll try this next
week.

I'm a bit puzzled about what to do if there's an internal bitmap. I can
ignore the issue at present because I only handle 1.1 and 1.2 metadata,
where any bitmap is stored before the start of the data area.

For metadata at the end of the disk, the bitmap will either be just before
or just after the superblock, and so I'll presumably need to move it to the
new end of the device along with the superblock. However, it looks at first
glance like the bitmap offset is constant across the array, not a per-device
setting. This suggests the bitmap has to move when the array is grown, not
earlier when rdev->size changes.

Unfortunately, that doesn't square with rdev->size being changed for
individual disks first! I can't move the bitmap without changing rdev->size
on all disks, but I can't increase rdev->size to a valid value on any disk
without moving the bitmap at the same point. Either I'm missing something,
or changing rdev->size online, drive-by-drive won't be possible if there's
an internal bitmap on a 0.90 or 1.0 format array.

I'm unlikely to get a chance to work on this again before Monday, but
I'd be very grateful for any feedback or pointers. md.c is a fairly
involved piece of code!

Cheers,

Chris.