0

I've created a RAID0 configuration with two 1GB EBS volumes, mounted at /dev/md0 using mdadm and formatted with XFS Next, I copied some files over to fill the volume to around 30% of its capacity (of 2GB)

I then created snapshots of the volumes using ec2-consistent-snapshot and created volumes of the said snapshots but specified the volume size to be 2GB (effective doubling the capacity on each disk)

I then spun up a new instance, assembled the RAID0 configuration on /dev/md0 from the 2 volumes mentioned above and mount it to /vol

df -hT showed /vol as 2GB (as expected)

Now I ran sudo xfs_growfs -d /vol. The command completed normally but reported blocks changed from 523776 to 524160 (only!) and df -hT still showed /vol as 2GB (instead of the expected 4GB)

I rebooted, remounted, reassembled the RAID but it still reports the old size.

EDIT: trying to grow the RAID using mdadm --grow yields mdadm: raid0 array /dev/md0 cannot be reshaped

Is there any other way I can grow a RAID0 array?

3
  • I can really strongly urge you not to do this, R0 is bad enough when you're using DAS, but using in a situation where the SLA is already wooly enough and where outages DO occur is I believe only asking for trouble. If you want so extra performance at least R10 them.
    – Chopper3
    Feb 27, 2011 at 12:10
  • I assume that EBS is a abstraction over a highly-redundant data store. If this is true then R10 would not add extra value. Feb 28, 2011 at 6:54
  • EBS is not highly-redundant - it's entirely possible to lose a volume. Per their docs: "As an example, volumes that operate with 20 GB or less of modified data since their most recent Amazon EBS snapshot can expect an annual failure rate (AFR) of between 0.1% – 0.5%, where failure refers to a complete loss of the volume."
    – ceejayoz
    Dec 13, 2012 at 21:50

2 Answers 2

0

One solution is to create new set of volumes from scratch (2GB each) and assemble a new RAID0 configuration in parallel (say, /dev/md1). Copy the files from one raid volume (/dev/md0) to the other (/dev/md1).

1
  • yup! thats what I thought. In the absence of any other replies, I'll accept yours and move on. Thanks! Feb 28, 2011 at 6:55
1

Use the --update=devicesize option when assembling your array. ie:

    mdadm --assemble --update=devicesize --scan

or

    mdadm --assemble --update=devicesize <device>

However, this requires that you are using at least v1.1 metadata, which puts the superblocks on the front of the devices. If you expand volumes using v0.90 or v1.0 metadata, you will have to recreate the array to put the new superblocks at the end of the devices. This is non-destructive to filesystems as long as you use the same options when creating the array as you did originally.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .