* Growing after replacing with larger discs
@ 2010-03-12 17:39 John Robinson
2010-03-12 18:00 ` Majed B.
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: John Robinson @ 2010-03-12 17:39 UTC (permalink / raw)
To: Linux RAID
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?
Cheers,
John.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-12 17:39 Growing after replacing with larger discs John Robinson
@ 2010-03-12 18:00 ` Majed B.
2010-03-12 18:04 ` John Robinson
2010-03-12 18:09 ` Luca Berra
[not found] ` <aebf5d971003131242q234a6c5ct441dd995a9c6a541@mail.gmail.com>
2 siblings, 1 reply; 12+ messages in thread
From: Majed B. @ 2010-03-12 18:00 UTC (permalink / raw)
To: John Robinson; +Cc: Linux RAID
I'm not sure if it is going to work or not, what you suggested.
But if you can run all disks at the same time, then why not create a
new array and copy the files over?
On Fri, Mar 12, 2010 at 8:39 PM, John Robinson
<john.robinson@anonymous.org.uk> 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?
>
> Cheers,
>
> John.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-12 18:00 ` Majed B.
@ 2010-03-12 18:04 ` John Robinson
2010-03-12 18:13 ` Majed B.
0 siblings, 1 reply; 12+ messages in thread
From: John Robinson @ 2010-03-12 18:04 UTC (permalink / raw)
To: Majed B.; +Cc: Linux RAID
On 12/03/2010 18:00, Majed B. wrote:
> I'm not sure if it is going to work or not, what you suggested.
>
> But if you can run all disks at the same time, then why not create a
> new array and copy the files over?
I can't, I only have the 3 drive caddies, so I was going to shut down,
start up from a CD, copy each drive individually, then put the 3 larger
drives in all at once.
Cheers,
John.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-12 17:39 Growing after replacing with larger discs John Robinson
2010-03-12 18:00 ` Majed B.
@ 2010-03-12 18:09 ` Luca Berra
2010-03-13 15:18 ` John Robinson
[not found] ` <aebf5d971003131242q234a6c5ct441dd995a9c6a541@mail.gmail.com>
2 siblings, 1 reply; 12+ messages in thread
From: Luca Berra @ 2010-03-12 18:09 UTC (permalink / raw)
To: Linux RAID
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
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-12 18:04 ` John Robinson
@ 2010-03-12 18:13 ` Majed B.
0 siblings, 0 replies; 12+ messages in thread
From: Majed B. @ 2010-03-12 18:13 UTC (permalink / raw)
To: Linux RAID
If you do this kind of thing a lot, or often enough, then it's better
to get a portable NAS, copy filesystem contents to it, then dump the
stuff back.
You can save yourself time with the new arrays by zeroing all the new
disks, and then when creating the new array, use assume-clean. That'll
prevent the array from resyncing, and you'll get full speed when
copying the filesystem contents back to the new array.
dd allows parallel writing to output devices.
On Fri, Mar 12, 2010 at 9:04 PM, John Robinson
<john.robinson@anonymous.org.uk> wrote:
> On 12/03/2010 18:00, Majed B. wrote:
>>
>> I'm not sure if it is going to work or not, what you suggested.
>>
>> But if you can run all disks at the same time, then why not create a
>> new array and copy the files over?
>
> I can't, I only have the 3 drive caddies, so I was going to shut down, start
> up from a CD, copy each drive individually, then put the 3 larger drives in
> all at once.
>
> Cheers,
>
> John.
>
>
--
Majed B.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-12 18:09 ` Luca Berra
@ 2010-03-13 15:18 ` John Robinson
2010-03-13 15:21 ` Majed B.
0 siblings, 1 reply; 12+ messages in thread
From: John Robinson @ 2010-03-13 15:18 UTC (permalink / raw)
To: Linux RAID
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-13 15:18 ` John Robinson
@ 2010-03-13 15:21 ` Majed B.
2010-03-13 18:13 ` John Robinson
0 siblings, 1 reply; 12+ messages in thread
From: Majed B. @ 2010-03-13 15:21 UTC (permalink / raw)
To: Linux RAID
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@anonymous.org.uk> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-13 15:21 ` Majed B.
@ 2010-03-13 18:13 ` John Robinson
2010-03-13 18:22 ` Majed B.
0 siblings, 1 reply; 12+ messages in thread
From: John Robinson @ 2010-03-13 18:13 UTC (permalink / raw)
To: Linux RAID
On 13/03/2010 15:21, Majed B. wrote:
> 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.
OK that's fair, you're right I don't want to risk losing data because I
was using a degraded array.
> 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.
I don't see whay either it'd require a resync - although I didn't say
it, I was planning to zero the rest of the larger drives and recreate
with --assume-clean - nor why data would be destroyed if I didn't create
with --assume-clean, after all the data will all be in the right place.
But I think on balance I'm going to save the contents of the original
array to an extra drive, create a new array on the big discs, and copy
the data back. It shouldn't take too much more time than copying the
discs individually with dd, even though I'm copying the data twice
rather than once, and it's both safer and gives me a free defrag.
Cheers,
John.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-13 18:13 ` John Robinson
@ 2010-03-13 18:22 ` Majed B.
2010-03-15 15:17 ` Stefan /*St0fF*/ Hübner
0 siblings, 1 reply; 12+ messages in thread
From: Majed B. @ 2010-03-13 18:22 UTC (permalink / raw)
To: Linux RAID
What I meant was: If you use dd to clone an old disk to a new one of a
larger size, metadata isn't where it should be and the new disk won't
be recognized as part of an array.
So if you do that to all disks, then attempt to create a new array on
the new disks, it will cause a resync. And even if it didn't resync,
data mapping may be incorrect.
For argument's sake, let's assume that cloning the disks would work.
It means cloning 3 disks.
The other option that you presented, which I hope you avoid, is
degrading the array and presenting the new disks. This would also
require 3 resyncs.
The option where you copy the data off the old array then back to the
new one consist of 2 copy operations only. May not be as fast as a dd
operation, but still should consume less time than 3 resyncs.
Also, while copying the original data, if the filesystem has problems,
you'll see them right away and probably identify which files are
affected. I hope everything goes smooth for you, but in case such
problems occur, do NOT run fsck!
Clone the filesystem first for best assurance of data safety.
Good luck!
On Sat, Mar 13, 2010 at 9:13 PM, John Robinson
<john.robinson@anonymous.org.uk> wrote:
> On 13/03/2010 15:21, Majed B. wrote:
>>
>> 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.
>
> OK that's fair, you're right I don't want to risk losing data because I was
> using a degraded array.
>
>> 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.
>
> I don't see whay either it'd require a resync - although I didn't say it, I
> was planning to zero the rest of the larger drives and recreate with
> --assume-clean - nor why data would be destroyed if I didn't create with
> --assume-clean, after all the data will all be in the right place.
>
> But I think on balance I'm going to save the contents of the original array
> to an extra drive, create a new array on the big discs, and copy the data
> back. It shouldn't take too much more time than copying the discs
> individually with dd, even though I'm copying the data twice rather than
> once, and it's both safer and gives me a free defrag.
>
> Cheers,
>
> John.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
[not found] ` <aebf5d971003131242q234a6c5ct441dd995a9c6a541@mail.gmail.com>
@ 2010-03-13 20:45 ` Beolach
2010-03-13 21:00 ` Majed B.
0 siblings, 1 reply; 12+ messages in thread
From: Beolach @ 2010-03-13 20:45 UTC (permalink / raw)
To: linux-raid
Forgot to send to the list...
On Sat, Mar 13, 2010 at 13:42, Beolach <beolach@gmail.com> wrote:
> On Fri, Mar 12, 2010 at 10:39, John Robinson
> <john.robinson@anonymous.org.uk> 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 have no idea if this would actually work, but maybe try partitioning
> the new, larger drives so the partitions are identical in size to the
> old discs, copying the old discs to the new partitions, starting the
> array with the new partitions, resizing the new partitions, and then
> running --grow. If mdadm can re-check the size of the member devices
> of a running array at --grow time, this might work, but if it only
> checks member device sizes at creation or assemble time, then it
> probably won't.
>
>
> Good luck,
> Conway S. Smith
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-13 20:45 ` Beolach
@ 2010-03-13 21:00 ` Majed B.
0 siblings, 0 replies; 12+ messages in thread
From: Majed B. @ 2010-03-13 21:00 UTC (permalink / raw)
To: LinuxRaid
Beolach,
That involves double the work!
On Sat, Mar 13, 2010 at 11:45 PM, Beolach <beolach@gmail.com> wrote:
> Forgot to send to the list...
>
> On Sat, Mar 13, 2010 at 13:42, Beolach <beolach@gmail.com> wrote:
>> On Fri, Mar 12, 2010 at 10:39, John Robinson
>> <john.robinson@anonymous.org.uk> 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 have no idea if this would actually work, but maybe try partitioning
>> the new, larger drives so the partitions are identical in size to the
>> old discs, copying the old discs to the new partitions, starting the
>> array with the new partitions, resizing the new partitions, and then
>> running --grow. If mdadm can re-check the size of the member devices
>> of a running array at --grow time, this might work, but if it only
>> checks member device sizes at creation or assemble time, then it
>> probably won't.
>>
>>
>> Good luck,
>> Conway S. Smith
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Growing after replacing with larger discs
2010-03-13 18:22 ` Majed B.
@ 2010-03-15 15:17 ` Stefan /*St0fF*/ Hübner
0 siblings, 0 replies; 12+ messages in thread
From: Stefan /*St0fF*/ Hübner @ 2010-03-15 15:17 UTC (permalink / raw)
To: Majed B.; +Cc: Linux RAID
Hi all,
Am 13.03.2010 19:22, schrieb Majed B.:
> What I meant was: If you use dd to clone an old disk to a new one of a
> larger size, metadata isn't where it should be and the new disk won't
> be recognized as part of an array.
I mean to have read that he uses 0.9 metadata. mdadm finds the device
size (i.e. partition size) and locates the metadata according to that.
So if he has partitioned the drives containing the raid, the dd-way
should work on one hand (if he clones the complete drive, not only the
partitions). On the other hand he'd have a backup at hand if something
goes terribly wrong. Or might I be mistaken now?
> So if you do that to all disks, then attempt to create a new array on
> the new disks, it will cause a resync. And even if it didn't resync,
> data mapping may be incorrect.
I second that - recreating is only good on same size devices - but
again: if the partition is same size, it should work.
>
> For argument's sake, let's assume that cloning the disks would work.
> It means cloning 3 disks.
Yes, using sgp_dd this works very well and quickly. And you don't have
problems arising from broken read-sectors being skipped. (yes, I know
there is conv=noerror,sync; but I had my problems with that...)
> The other option that you presented, which I hope you avoid, is
> degrading the array and presenting the new disks. This would also
> require 3 resyncs.
Yes, that is a bad idea.
> The option where you copy the data off the old array then back to the
> new one consist of 2 copy operations only. May not be as fast as a dd
> operation, but still should consume less time than 3 resyncs.
right on one hand. the other hand is: on my laboratory computer (which
is used for raid-recoveries and such) 4 parallel sgp_dd operations work
at about 90MB/s (if the drives are quick enough, starting with 115MB/s,
and sinking speed as the r/w-heads move outside). But one copy only
reaches 50MB/s. Multiple parallel copies do not give any speedup.
>
> Also, while copying the original data, if the filesystem has problems,
> you'll see them right away and probably identify which files are
> affected. I hope everything goes smooth for you, but in case such
> problems occur, do NOT run fsck!
second that - if fsck is needed, create a dd-backup to run it on.
> Clone the filesystem first for best assurance of data safety.
>
> Good luck!
>
[...]
Also my best wishes for the operation...
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-03-15 15:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-12 17:39 Growing after replacing with larger discs John Robinson
2010-03-12 18:00 ` Majed B.
2010-03-12 18:04 ` John Robinson
2010-03-12 18:13 ` Majed B.
2010-03-12 18:09 ` Luca Berra
2010-03-13 15:18 ` John Robinson
2010-03-13 15:21 ` Majed B.
2010-03-13 18:13 ` John Robinson
2010-03-13 18:22 ` Majed B.
2010-03-15 15:17 ` Stefan /*St0fF*/ Hübner
[not found] ` <aebf5d971003131242q234a6c5ct441dd995a9c6a541@mail.gmail.com>
2010-03-13 20:45 ` Beolach
2010-03-13 21:00 ` Majed B.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).