Growing RAID1 array with bitmaps enabled

[Bryan Mesich <bryan.mesich@ndsu.edu>]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

Good evening to all,

I'm looking at growing a RAID1 array from 40GB to 100GB.  The
array has a write-intent bitmap enabled, but an email from Neil 
in August suggests that I should disable the bitmap when 
growing the array. Here's a bit of the email Neil sent to the 
list:

>We cannot currently change the size of a write-intent bitmap.
>So if we change the size of an array which has such a bitmap, it
>tries to set bits beyond the end of the bitmap.
>
>For now, simply reject any request to change the size of an array
>which has a bitmap.  mdadm can remove the bitmap and add a new
>one after the array has changed size.
>
[snip...]

A couple questions I have:

1) Does the superblock increase in size when the array is grown 
to make room for a larger bitmap?  (This doesn't seem possible 
to me, particularly if using a v1.1 or v1.2 superblock).

or...

2) Is the problem mentioned in Neil's email in regard to a
"restructuring" of the bitmap to accommodate a larger array (i.e. 
We only have "x" amount of room on the superblock, so re-divide 
the array into chucks that we can fit into the superblock)?

In my use case, the block devices that compose the RAID1 array
are fibre channel SAN volumes.  When I grow them to 100GB on the 
FC target, the additional 60GB is appended to the end of the
exported block device.  My out-of-sync data will still be present 
on the first 40GB.

With this in mind (and the adage that patches are welcome), has there 
been any interest in being able to use a write-intent bitmap for this 
kind of use case?  The benefit of this functionality would keep me 
from eating two _full_ re-syncs on the array when growing the block 
devices.


Thanks in advance,

Bryan

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]