All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan /*St0fF*/ Hübner" <stefan.huebner@stud.tu-ilmenau.de>
To: "Majed B." <majedb@gmail.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Growing after replacing with larger discs
Date: Mon, 15 Mar 2010 16:17:52 +0100	[thread overview]
Message-ID: <4B9E4FA0.9060609@stud.tu-ilmenau.de> (raw)
In-Reply-To: <70ed7c3e1003131022o78b065b3oadeb1a309cdc995f@mail.gmail.com>

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

  reply	other threads:[~2010-03-15 15:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
     [not found] ` <aebf5d971003131242q234a6c5ct441dd995a9c6a541@mail.gmail.com>
2010-03-13 20:45   ` Beolach
2010-03-13 21:00     ` Majed B.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B9E4FA0.9060609@stud.tu-ilmenau.de \
    --to=stefan.huebner@stud.tu-ilmenau.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=majedb@gmail.com \
    --cc=st0ff@npl.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.