From: NeilBrown <neilb@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 004 of 10] md: Allow re-add to work on array without bitmaps.
Date: Thu, 1 Jun 2006 15:13:42 +1000 [thread overview]
Message-ID: <1060601051342.27589@suse.de> (raw)
In-Reply-To: 20060601150955.27444.patches@notabene
When an array has a bitmap, a device can be removed and re-added
and only blocks changes since the removal (as recorded in the bitmap)
will be resynced.
It should be possible to do a similar thing to arrays without bitmaps.
i.e. if a device is removed and re-added and *no* changes have been
made in the interim, then the add should not require a resync.
This patch allows that option.
This means that when assembling an array one device at a time (e.g.
during device discovery) the array can be enabled read-only as soon
as enough devices are available, but extra devices can still be added
without causing a resync.
Signed-off-by: Neil Brown <neilb@suse.de>
### Diffstat output
./drivers/md/md.c | 25 ++++++++++++++-----------
./drivers/md/raid1.c | 6 ++++++
2 files changed, 20 insertions(+), 11 deletions(-)
diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~ 2006-06-01 15:03:28.000000000 +1000
+++ ./drivers/md/md.c 2006-06-01 15:05:29.000000000 +1000
@@ -737,6 +737,7 @@ static int super_90_validate(mddev_t *md
{
mdp_disk_t *desc;
mdp_super_t *sb = (mdp_super_t *)page_address(rdev->sb_page);
+ __u64 ev1 = md_event(sb);
rdev->raid_disk = -1;
rdev->flags = 0;
@@ -753,7 +754,7 @@ static int super_90_validate(mddev_t *md
mddev->layout = sb->layout;
mddev->raid_disks = sb->raid_disks;
mddev->size = sb->size;
- mddev->events = md_event(sb);
+ mddev->events = ev1;
mddev->bitmap_offset = 0;
mddev->default_bitmap_offset = MD_SB_BYTES >> 9;
@@ -802,7 +803,6 @@ static int super_90_validate(mddev_t *md
} else if (mddev->pers == NULL) {
/* Insist on good event counter while assembling */
- __u64 ev1 = md_event(sb);
++ev1;
if (ev1 < mddev->events)
return -EINVAL;
@@ -810,11 +810,13 @@ static int super_90_validate(mddev_t *md
/* if adding to array with a bitmap, then we can accept an
* older device ... but not too old.
*/
- __u64 ev1 = md_event(sb);
if (ev1 < mddev->bitmap->events_cleared)
return 0;
- } else /* just a hot-add of a new device, leave raid_disk at -1 */
- return 0;
+ } else {
+ if (ev1 < mddev->events)
+ /* just a hot-add of a new device, leave raid_disk at -1 */
+ return 0;
+ }
if (mddev->level != LEVEL_MULTIPATH) {
desc = sb->disks + rdev->desc_nr;
@@ -1105,6 +1107,7 @@ static int super_1_load(mdk_rdev_t *rdev
static int super_1_validate(mddev_t *mddev, mdk_rdev_t *rdev)
{
struct mdp_superblock_1 *sb = (struct mdp_superblock_1*)page_address(rdev->sb_page);
+ __u64 ev1 = le64_to_cpu(sb->events);
rdev->raid_disk = -1;
rdev->flags = 0;
@@ -1120,7 +1123,7 @@ static int super_1_validate(mddev_t *mdd
mddev->layout = le32_to_cpu(sb->layout);
mddev->raid_disks = le32_to_cpu(sb->raid_disks);
mddev->size = le64_to_cpu(sb->size)/2;
- mddev->events = le64_to_cpu(sb->events);
+ mddev->events = ev1;
mddev->bitmap_offset = 0;
mddev->default_bitmap_offset = 1024 >> 9;
@@ -1154,7 +1157,6 @@ static int super_1_validate(mddev_t *mdd
} else if (mddev->pers == NULL) {
/* Insist of good event counter while assembling */
- __u64 ev1 = le64_to_cpu(sb->events);
++ev1;
if (ev1 < mddev->events)
return -EINVAL;
@@ -1162,12 +1164,13 @@ static int super_1_validate(mddev_t *mdd
/* If adding to array with a bitmap, then we can accept an
* older device, but not too old.
*/
- __u64 ev1 = le64_to_cpu(sb->events);
if (ev1 < mddev->bitmap->events_cleared)
return 0;
- } else /* just a hot-add of a new device, leave raid_disk at -1 */
- return 0;
-
+ } else {
+ if (ev1 < mddev->events)
+ /* just a hot-add of a new device, leave raid_disk at -1 */
+ return 0;
+ }
if (mddev->level != LEVEL_MULTIPATH) {
int role;
rdev->desc_nr = le32_to_cpu(sb->dev_number);
diff ./drivers/md/raid1.c~current~ ./drivers/md/raid1.c
--- ./drivers/md/raid1.c~current~ 2006-06-01 15:03:28.000000000 +1000
+++ ./drivers/md/raid1.c 2006-06-01 15:05:29.000000000 +1000
@@ -1625,6 +1625,12 @@ static sector_t sync_request(mddev_t *md
/* before building a request, check if we can skip these blocks..
* This call the bitmap_start_sync doesn't actually record anything
*/
+ if (mddev->bitmap == NULL &&
+ mddev->recovery_cp == MaxSector &&
+ conf->fullsync == 0) {
+ *skipped = 1;
+ return max_sector - sector_nr;
+ }
if (!bitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks, 1) &&
!conf->fullsync && !test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery)) {
/* We can skip this block, and probably several more */
next prev parent reply other threads:[~2006-06-01 5:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-01 5:13 [PATCH 000 of 10] md: Introduction - assorted patches for -mm NeilBrown
2006-06-01 5:13 ` [PATCH 001 of 10] md: md Kconfig speeling feex NeilBrown
2006-06-01 5:13 ` [PATCH 002 of 10] md: Fix Kconfig error NeilBrown
2006-06-01 5:13 ` [PATCH 003 of 10] md: Fix bug that stops raid5 resync from happening NeilBrown
2006-06-01 5:13 ` NeilBrown [this message]
2006-06-01 5:13 ` [PATCH 005 of 10] md: Don't write dirty/clean update to spares - leave them alone NeilBrown
2006-06-01 5:13 ` [PATCH 006 of 10] md: Set/get state of array via sysfs NeilBrown
2006-06-01 5:33 ` Chris Wright
2006-06-01 5:43 ` Neil Brown
2006-06-01 5:14 ` [PATCH 007 of 10] md: Allow rdev state to be set " NeilBrown
2006-06-01 5:14 ` [PATCH 008 of 10] md: Allow raid 'layout' to be read and " NeilBrown
2006-06-01 5:34 ` Chris Wright
2006-06-01 5:44 ` Neil Brown
2006-06-01 5:14 ` [PATCH 009 of 10] md: Allow resync_start to be set and queried " NeilBrown
2006-06-01 5:14 ` [PATCH 010 of 10] md: Allow the write_mostly flag to be set " NeilBrown
2006-08-05 5:59 ` Mike Snitzer
2006-08-05 23:43 ` Mike Snitzer
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=1060601051342.27589@suse.de \
--to=neilb@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
/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 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).