Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
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 '11 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. –  Ryan Fernandes Feb 28 '11 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 '12 at 21:50

2 Answers 2

up vote 0 down vote accepted

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).

share|improve this answer
    
yup! thats what I thought. In the absence of any other replies, I'll accept yours and move on. Thanks! –  Ryan Fernandes Feb 28 '11 at 6:55

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.