Shrinking on-disk size of RAID1 array?

Hi,

I'm hoping to shrink the per-component size of an active RAID1 array, so that I can transition the array to a smaller, faster set of drives.

It appears I could do this by first shrinking the filesystem (ext3) with 'parted' as described here...

http://www.gnu.org/software/parted/manual/html_mono/parted.html#SEC68

...and then use 'mdadm' with the '--grow' and '--size' options to shrink my RAID1 array's extent on disks.

But, I can't find a reference to doing exactly this online, the 'mdadm' man page is a little thin on 'grow' details, and there's at least one suggestion that the 'mdadm' man page is wrong about the units to use in the '--size' parameter. (See

http://www.issociate.de/board/post/250478/error_in_mdadm_man_page.html
)

So, could someone "in the know" give a sanity check to my plan?

I've got a 2.6.12 kernel and I've got the following RAID1 arrays...

# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdc3[2] sdb3[1] sda3[0]
      154087360 blocks [3/3] [UUU]

md0 : active raid1 sdc1[1] sdb1[2] sda1[0]

      104320 blocks [3/3] [UUU]

unused devices: <none>

I want to shrink /dev/md1 to about 70GB. The constituent physical partitions look like this...

# fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          13      104391   fd  Linux raid autodetect
/dev/sda2              14         274     2096482+  82  Linux swap
/dev/sda3             275       19457   154087447+  fd  Linux raid autodetect

I presume I should boot from a CD, then without /dev/md1 mounted, follow the instructions from the 'parted' docs to resize filesystem to 70000 megabytes (or is it mebibytes? the 'parted' doc isn't clear):

# parted /dev/md1
(parted) resize 1 0 70000
(parted) quit

Then, use 'mdadm' to shrink the array to the right size (which I'm assuming is 70000MiB*1024KiB/MiB == 71680000 kebibytes):

# mdadm --grow /dev/md1 --size 71680000

Then reboot, and all should be well at the smaller size.

My main concerns:
(1) Are these the right steps? (Missing anything?)
(2) Are the 'parted' units truly meGAbytes?
(3) How should the 'mdadm' '--size' parameter be related to the 'parted' parameter? (Is the man bug report suggesting the '--size' must be specified in bytes, not kebibytes, accurate? Do I have to deduct the 128K superblock space, or is that done automatically?)

Thanks for any guidance!

- Gordon @ Bitzi

I may be missing something here, but why not connect up the new drives, setup the arrays, simply cp -R * everything over to the new filesystems and update fstab and mdadm.conf? I can understand wanting to let the system handle it all for you, but this way you'll get a free defrag to boot :)

Largest reason is that I want to minimize system downtime. My working assumption is that the 'parted' resize and 'mdadm' grow (shrink) would take minutes (or tens of minutes), then the background sync to the new smaller drive could happen at a leisurely pace, while services which actively write to the array remain up.

I would expect a plain 'cp -R' to take hours, during which (to be safe) all services using the array should be stopped. (Perhaps I could do an initial 'cp -R' while services are running, then a quicker rsync for consistency when services are down?)

If my assumption about the relative time required of 'parted' resize and 'mdadm' grow is wrong, the simple copy approach would be more attractive.

- Gordon