public inbox for lvm2-cvs@sourceware.org
help / color / mirror / Atom feed
From: wysochanski@sourceware.org
To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org
Subject: LVM2/lib/metadata metadata.c
Date: Mon, 28 Jun 2010 20:35:00 -0000	[thread overview]
Message-ID: <20100628203550.16904.qmail@sourceware.org> (raw)

CVSROOT:	/cvs/lvm2
Module name:	LVM2
Changes by:	wysochanski@sourceware.org	2010-06-28 20:35:49

Modified files:
	lib/metadata   : metadata.c 

Log message:
	Before committing each mda, arrange mdas so ignored mdas get committed first.
	
	Arrange mdas so mdas that are to be ignored come first.  This is an
	optimization that ensures consistency on disk for the longest period of time.
	This was noted by agk in review of the v4 patchset of pvchange-based mda
	balance.
	
	Note the following example for an explanation of the background:
	Assume the initial state on disk is as follows:
	PV0 (v1, non-ignored)
	PV1 (v1, non-ignored)
	PV2 (v1, non-ignored)
	PV3 (v1, non-ignored)
	
	If we did not sort the list, we would have a commit sequence something like
	this:
	PV0 (v2, non-ignored)
	PV1 (v2, ignored)
	PV2 (v2, ignored)
	PV3 (v2, non-ignored)
	
	After the commit of PV0's mdas, we'd have an on-disk state like this:
	PV0 (v2, non-ignored)
	PV1 (v1, non-ignored)
	PV2 (v1, non-ignored)
	PV3 (v1, non-ignored)
	
	This is an inconsistent state of the disk. If the machine fails, the next
	time it was brought back up, the auto-correct mechanism in vg_read would
	update the metadata on PV1-PV3.  However, if possible we try to avoid
	inconsistent on-disk states.  Clearly, because we did not sort, we have
	a greater chance of on-disk inconsistency - from the time the commit of
	PV0 is complete until the time PV3 is complete.
	
	We could improve the amount of time the on-disk state is consistent by simply
	sorting the commit order as follows:
	PV1 (v2, ignored)
	PV2 (v2, ignored)
	PV0 (v2, non-ignored)
	PV3 (v2, non-ignored)
	
	Thus, after the first PV is committed (in this case PV1), on-disk we would
	have:
	PV0 (v1, non-ignored)
	PV1 (v2, ignored)
	PV2 (v1, non-ignored)
	PV3 (v1, non-ignored)
	
	This is clearly a consistent state.  PV1 will be read but the mda will be
	ignored.  All other PVs contain v1 metadata, and no auto-correct will be
	required.  In fact, if we commit all PVs with ignored mdas first, we'll
	only have an inconsistent state when we start writing non-ignored PVs,
	and thus the chances we'll get an inconsistent state on disk is much
	less with the sorted method.
	
	Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.c.diff?cvsroot=lvm2&r1=1.356&r2=1.357

--- LVM2/lib/metadata/metadata.c	2010/06/28 20:35:33	1.356
+++ LVM2/lib/metadata/metadata.c	2010/06/28 20:35:49	1.357
@@ -2426,10 +2426,21 @@
 
 static int _vg_commit_mdas(struct volume_group *vg)
 {
-	struct metadata_area *mda;
+	struct metadata_area *mda, *tmda;
+	struct dm_list ignored;
 	int failed = 0;
 	int cache_updated = 0;
 
+	/* Rearrange the metadata_areas_in_use so ignored mdas come first. */
+	dm_list_init(&ignored);
+	dm_list_iterate_items_safe(mda, tmda, &vg->fid->metadata_areas_in_use) {
+		if (mda_is_ignored(mda))
+			dm_list_move(&ignored, &mda->list);
+	}
+	dm_list_iterate_items_safe(mda, tmda, &ignored) {
+		dm_list_move(&vg->fid->metadata_areas_in_use, &mda->list);
+	}
+
 	/* Commit to each copy of the metadata area */
 	dm_list_iterate_items(mda, &vg->fid->metadata_areas_in_use) {
 		failed = 0;


             reply	other threads:[~2010-06-28 20:35 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28 20:35 wysochanski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-03-12 14:43 zkabelac
2012-03-01  9:46 zkabelac
2012-02-29  0:19 mornfall
2012-02-29  0:18 mornfall
2012-02-28 11:10 zkabelac
2012-02-27  9:54 zkabelac
2012-02-12 20:19 agk
2012-01-25  8:50 zkabelac
2011-04-01 14:54 prajnoha
2011-03-30 13:35 zkabelac
2011-03-10 22:39 zkabelac
2011-02-21 12:13 prajnoha
2011-02-14 19:27 mornfall
2010-12-14 17:07 mornfall
2010-11-30 11:15 mornfall
2010-10-25 13:35 zkabelac
2010-07-30 16:47 wysochanski
2010-07-09 16:57 wysochanski
2010-07-08 17:41 wysochanski
2010-07-06 20:09 agk
2010-07-06 17:29 agk
2010-07-06 17:27 agk
2010-07-06 17:26 agk
2010-06-30 19:55 wysochanski
2010-06-30 14:54 agk
2010-06-30 14:52 agk
2010-06-30 14:48 wysochanski
2010-06-30 14:27 agk
2010-06-28 20:38 wysochanski
2010-06-28 20:38 wysochanski
2010-06-28 20:37 wysochanski
2010-06-28 20:35 wysochanski
2010-04-08 15:18 wysochanski
2010-04-06 14:03 wysochanski
2010-04-01 13:08 agk
2010-04-01 11:45 agk
2010-02-24 18:15 wysochanski
2010-01-21 21:04 wysochanski
2010-01-21 21:04 wysochanski
2010-01-07 14:29 zkabelac
2009-12-16 19:26 mornfall
2009-11-19 13:44 mornfall
2009-10-05 20:02 wysochanski
2009-10-05 20:02 wysochanski
2009-09-02 21:39 wysochanski
2009-08-10 17:15 wysochanski
2009-07-28 20:41 agk
2009-07-26 12:41 wysochanski
2009-07-26  1:53 wysochanski
2009-07-26  1:52 wysochanski
2009-07-24 15:15 wysochanski
2009-07-16 20:18 wysochanski
2009-07-01 17:03 wysochanski
2009-06-10 16:14 wysochanski
2009-05-13  1:48 agk
2009-04-28 17:46 wysochanski
2009-04-10 10:01 mbroz
2009-04-02 15:01 mbroz
2009-02-23 16:53 mbroz
2009-01-26 22:22 agk
2008-08-13 13:42 zkabelac
2008-01-22 16:02 agk
2008-01-16 22:52 agk
2007-10-12 21:08 wysochanski
2007-08-06 21:11 wysochanski
2007-07-12  4:12 wysochanski
2007-06-13 21:14 wysochanski
2007-06-12 21:39 wysochanski
2006-10-07 23:06 agk
2005-04-19 20:44 agk
2005-04-17 23:59 agk
2004-03-26 21:07 agk

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=20100628203550.16904.qmail@sourceware.org \
    --to=wysochanski@sourceware.org \
    --cc=lvm-devel@redhat.com \
    --cc=lvm2-cvs@sourceware.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 read-only IMAP folder(s) and NNTP newsgroup(s).