All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Suresh Babu Kandukuru <suresh.babu.kandukuru@oracle.com>,
	linux-raid@vger.kernel.org
Subject: Re: RAID 1 metadata - keep separate from mirror disks ?
Date: Wed, 11 Feb 2015 09:49:20 -0500	[thread overview]
Message-ID: <54DB6BF0.3040309@turmel.org> (raw)
In-Reply-To: <79c7cd53-bb6c-4058-95ad-7ebd56cf1056@default>

Good morning Suresh,

On 02/11/2015 07:14 AM, Suresh Babu Kandukuru wrote:
> Hi There,
> 
> On the RAID 1  metadata: is there  any way to keep the metadata
> separate from the mirror disks?  Could you  guide us on this ?,
> please. In general, we need to keep all metadata off the device
> itself, leaving all the device available for user data. This is
> particularly important in the migration case, where we want to take
> an existing LUN and add a second leg to it to create the mirror
> device without changing any of the data or metadata on the LUN.

If you look at "man 4 md" you'll see some options.  If a legacy array
type meets your needs, you can operate without metadata at all.  Use
"mdadm --build" to assemble your raid at each boot.

Or, if your storage server can insert a leg ahead of you current LUN,
you can then create the array with an explicit data offset matching the
size of the inserted leg.  Create it degraded with the existing LUN,
then add (a) LUN(s) to start mirroring.  This process will leave you the
option to resize with more legs later.

Or you can add a leg to the end and create your array with version 1.0
metadata, which is placed at the end of the device.

Finally, you could write your own metadata container service for use
with mdmon.  (That's a bit beyond my ability, sorry.)

Phil

  reply	other threads:[~2015-02-11 14:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-11 12:14 RAID 1 metadata - keep separate from mirror disks ? Suresh Babu Kandukuru
2015-02-11 14:49 ` Phil Turmel [this message]
2015-02-12 11:42   ` Suresh Babu Kandukuru
2015-02-16 11:37   ` Suresh Babu Kandukuru
2015-02-16 13:02     ` Phil Turmel

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=54DB6BF0.3040309@turmel.org \
    --to=philip@turmel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=suresh.babu.kandukuru@oracle.com \
    /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.