From: Neil Brown <neilb@suse.de>
To: Michael Sallaway <michael@sallaway.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: 3-way mirrors
Date: Wed, 8 Sep 2010 14:16:21 +1000 [thread overview]
Message-ID: <20100908141621.0f6221aa@notabene> (raw)
In-Reply-To: <20100908035852.25019.qmail@s217.sureserver.com>
On Wed, 08 Sep 2010 03:58:52 +0000
"Michael Sallaway" <michael@sallaway.com> wrote:
> > From: Neil Brown <neilb@suse.de>
> > Subject: Re: 3-way mirrors
> > Sent: 07 Sep '10 22:01
> >
> > This is already possible via the sync_min and sync_max sysfs files.
> > Write a number of sectors to sync_max and a lower number to sync_min.
> > Then write 'repair' to 'sync_action'.
> > When sync_completed reaches sync_max, the repair will pause.
> > You can then let it continue by writing a larger number to sync_max, or tell
> > it to finish by writing 'idle' to 'sync_action'.
>
> Interesting... will this also work for a rebuild/recovery? If so, how do I start a rebuild from a particular location? (do I just write the sync_min sector before adding the replacement drive to the array, and it will start from there when I add it?)
Why would you want to?
sync_min is only honoured when you request a check/repair operation. When md
determines a resync or recovery is needed, it starts the where it needs to
start from, which is normally the beginning.
You can add a new device entirely by writing to sysfs files. In this case
you can set the 'recovery_start' for that device. This tells md that it has
already recovered some of the array.
>
> Are all sector counts in terms of a drive sector position, or an array sector position?
For raid10, the sector counts are array sector position.
For raid5/raid6, the sector counts are drive sector position with data_offset
subtracted (so they start from 0).
For raid1, both of the above descriptions produce the same answer, so both
are valid descriptions.
NeilBrown
>
> Thanks,
> Michael
> --
> 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
next prev parent reply other threads:[~2010-09-08 4:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 3:58 3-way mirrors Michael Sallaway
2010-09-08 4:16 ` Neil Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-09-08 7:01 Michael Sallaway
2010-09-08 9:11 ` Tim Small
2010-09-08 6:16 Michael Sallaway
2010-09-08 6:40 ` Neil Brown
2010-09-08 9:06 ` Tim Small
2010-09-08 5:45 Michael Sallaway
2010-09-08 6:02 ` Neil Brown
2010-09-07 14:19 George Spelvin
2010-09-07 16:07 ` Iordan Iordanov
2010-09-07 18:49 ` George Spelvin
2010-09-07 19:55 ` Keld Jørn Simonsen
2010-09-07 18:31 ` Aryeh Gregor
2010-09-07 19:02 ` George Spelvin
2010-09-08 22:28 ` Bill Davidsen
2010-09-07 22:01 ` Neil Brown
2010-09-08 1:33 ` Neil Brown
2010-09-08 14:52 ` George Spelvin
2010-09-08 23:04 ` Neil Brown
2010-09-28 16:42 ` Tim Small
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=20100908141621.0f6221aa@notabene \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--cc=michael@sallaway.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.