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;
next 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: linkBe 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).