Re: Growing after replacing with larger discs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You should never degrade the array to copy its contents. Its very
risky. There might be bad sectors on one or more disks and if you
don't have all disks at hand, you may not be able to rebuild the array
on the new disk.

As for using dd, as others have pointed, the metadata won't be in
place and if you create a new array after using dd, it'll still
require a resync and the data will be destroyed.

On Sat, Mar 13, 2010 at 6:18 PM, John Robinson
<john.robinson@xxxxxxxxxxxxxxxx> wrote:
> On 12/03/2010 18:09, Luca Berra wrote:
>>
>> On Fri, Mar 12, 2010 at 05:39:47PM +0000, John Robinson wrote:
>>>
>>> Before I have to go to a customer's premises and try it, I wanted to ask
>>> if anyone had already done anything like this: I have a CentOS 5 system with
>>> 0.90 metadata and type fd partitions with RAID-5 over 3 discs. I want to
>>> grow it by replacing the drives. If I dd the small partitions onto larger
>>> ones on the new discs, then reboot, will the system recognise the RAID-5 -
>>> which now has its metadata somewhere in the middle of the paritions not at
>>> the end - so that I can then --grow?
>>
>> I believe it won't work
>> mdadm has no way to know where the metadata is in the above case.
>>
>> you have to follow the painful procedure
>> fail one drive (mdadm /dev/mdX --fail /dev/sdY)
>> remove it (mdadm /dev/mdX --remove /dev/sdY)
>> replace drive with larger one
>> create larger partition
>> add drive again (mdadm /dev/mdX --add /dev/sdY)
>> wait for it to resync...
>> ...and repeat until all drives have been replaced
>
> Yeuch. That'll take forever, because I'd need to rebuild 3 times. I see two
> other options:
> (1) dd the drives as I said originally, and when the system can't find the
> array on the bigger discs, recreate the array using the same options the
> original array had
> (2) degrade the existing array to two discs, replace the soft-failed disc
> with one of the new discs, temporarily make a filesystem on it, copy the
> data; replace the other two discs, make a new array on them with a missing
> drive, copy the data back; scrub the temporarily-made filesystem and add the
> drive to the array.
>
> Actually I think something along the lines of Majed B's suggestion - in this
> case hang a spare drive out the side of the chassis, and just copy twice -
> would be quicker than (2). But (1) should work, shouldn't it?
>
> Cheers,
>
> John.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
       Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux