public inbox for lvm2-cvs@sourceware.org help / color / mirror / Atom feed
From: jbrassow@sourceware.org To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org Subject: LVM2 ./WHATS_NEW lib/metadata/raid_manip.c Date: Wed, 11 Apr 2012 14:20:00 -0000 [thread overview] Message-ID: <20120411142021.21095.qmail@sourceware.org> (raw) CVSROOT: /cvs/lvm2 Module name: LVM2 Changes by: jbrassow@sourceware.org 2012-04-11 14:20:20 Modified files: . : WHATS_NEW lib/metadata : raid_manip.c Log message: Fix inability to split RAID1 image while specifying a particular PV. The logic for resuming the original and newly split LVs was not properly done to handle situations where anything but the last device in the array was split. It did not take into account the possible name collisions that might occur when the original LV undergoes the shifting and renaming of its sub-LVs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2382&r2=1.2383 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/raid_manip.c.diff?cvsroot=lvm2&r1=1.26&r2=1.27 --- LVM2/WHATS_NEW 2012/04/11 12:42:10 1.2382 +++ LVM2/WHATS_NEW 2012/04/11 14:20:19 1.2383 @@ -1,5 +1,6 @@ Version 2.02.96 - ================================ + Fix inability to split RAID1 image while specifying a particular PV. Update man pages to give them same look&feel. Fix lvresize of thin pool for stipped devices. For lvresize round upward when specifying number of extents. --- LVM2/lib/metadata/raid_manip.c 2012/04/11 01:23:29 1.26 +++ LVM2/lib/metadata/raid_manip.c 2012/04/11 14:20:20 1.27 @@ -64,6 +64,24 @@ return seg->area_count; } +/* + * Resume sub-LVs first, then top-level LV + */ +static int _bottom_up_resume(struct logical_volume *lv) +{ + uint32_t s; + struct lv_segment *seg = first_seg(lv); + + if (seg_is_raid(seg) && (seg->area_count > 1)) { + for (s = 0; s < seg->area_count; s++) + if (!resume_lv(lv->vg->cmd, seg_lv(seg, s)) || + !resume_lv(lv->vg->cmd, seg_metalv(seg, s))) + return_0; + } + + return resume_lv(lv->vg->cmd, lv); +} + static int _activate_sublv_preserving_excl(struct logical_volume *top_lv, struct logical_volume *sub_lv) { @@ -975,8 +993,6 @@ static int _raid_remove_images(struct logical_volume *lv, uint32_t new_count, struct dm_list *pvs) { - uint32_t s; - struct lv_segment *seg; struct dm_list removal_list; struct lv_list *lvl; @@ -1035,13 +1051,7 @@ * tries to rename first, it will collide with the existing * position 1. */ - seg = first_seg(lv); - for (s = 0; (new_count > 1) && (s < seg->area_count); s++) { - if (!resume_lv(lv->vg->cmd, seg_lv(seg, s)) || - !resume_lv(lv->vg->cmd, seg_metalv(seg, s))) - return_0; - } - if (!resume_lv(lv->vg->cmd, lv)) { + if (!_bottom_up_resume(lv)) { log_error("Failed to resume %s/%s after committing changes", lv->vg->name, lv->name); return 0; @@ -1193,22 +1203,33 @@ } /* - * Resume original LV - * This also resumes all other sub-lvs (including the extracted) + * First resume the newly split LV and LVs on the removal list. + * This is necessary so that there are no name collisions due to + * the original RAID LV having possibly had sub-LVs that have been + * shifted and renamed. + */ + if (!resume_lv(cmd, lvl->lv)) + return_0; + dm_list_iterate_items(lvl, &removal_list) + if (!resume_lv(cmd, lvl->lv)) + return_0; + + /* + * Resume the remaining LVs + * We must start by resuming the sub-LVs first (which would + * otherwise be handled automatically) because the shifting + * of positions could otherwise cause name collisions. For + * example, if position 0 of a 3-way array is split, position + * 1 and 2 must be shifted and renamed 0 and 1. If position 2 + * tries to rename first, it will collide with the existing + * position 1. */ - if (!resume_lv(cmd, lv)) { + if (!_bottom_up_resume(lv)) { log_error("Failed to resume %s/%s after committing changes", lv->vg->name, lv->name); return 0; } - /* Recycle newly split LV so it is properly renamed */ - if (!suspend_lv(cmd, lvl->lv) || !resume_lv(cmd, lvl->lv)) { - log_error("Failed to rename %s to %s after committing changes", - old_name, split_name); - return 0; - } - /* * Eliminate the residual LVs */
next reply other threads:[~2012-04-11 14:20 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-11 14:20 jbrassow [this message] -- strict thread matches above, loose matches on Subject: below -- 2012-04-24 20:05 jbrassow 2012-04-12 3:16 jbrassow 2012-04-11 1:23 jbrassow 2012-02-13 11:10 zkabelac 2011-12-01 0:21 jbrassow 2011-09-13 16:33 jbrassow 2011-08-18 19:31 jbrassow
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=20120411142021.21095.qmail@sourceware.org \ --to=jbrassow@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).