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/lv_manip.c lib/m ... Date: Thu, 23 Feb 2012 03:57:00 -0000 [thread overview] Message-ID: <20120223035724.3768.qmail@sourceware.org> (raw) CVSROOT: /cvs/lvm2 Module name: LVM2 Changes by: jbrassow@sourceware.org 2012-02-23 03:57:23 Modified files: . : WHATS_NEW lib/metadata : lv_manip.c raid_manip.c Log message: Fix allocation code to allow replacement of single RAID 4/5/6 device. The code fail to account for the case where we just need a single device in a RAID 4/5/6 array. There is no good way to tell the allocation functions that we don't need parity devices when we are allocating just a single device. So, I've used a bit of a hack. If we are allocating an area_count that is <= the parity count, then we can assume we are simply allocating a replacement device (i.e. no need to include parity devices in the calculations). This should make sense in most cases. If we need to allocate replacement devices due to failure (or moving), we will never allocate more than the parity count; or we would cause the array to become unusable. If we are creating a new device, we should always create more stripes than parity devices. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2301&r2=1.2302 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_manip.c.diff?cvsroot=lvm2&r1=1.363&r2=1.364 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/raid_manip.c.diff?cvsroot=lvm2&r1=1.22&r2=1.23 --- LVM2/WHATS_NEW 2012/02/23 00:11:01 1.2301 +++ LVM2/WHATS_NEW 2012/02/23 03:57:23 1.2302 @@ -1,5 +1,6 @@ Version 2.02.93 - ==================================== + Fix allocation code to allow replacement of single RAID 4/5/6 device. Check all tags and LV names are in a valid form in vg_validate. Add tmpfiles.d style configuration for lvm2 lock and run directory. Add configure --with-tmpfilesdir for dir holding volatile-file configuration. --- LVM2/lib/metadata/lv_manip.c 2012/02/22 17:14:39 1.363 +++ LVM2/lib/metadata/lv_manip.c 2012/02/23 03:57:23 1.364 @@ -737,7 +737,7 @@ struct dm_list *parallel_areas) { struct alloc_handle *ah; - uint32_t s, area_count, alloc_count; + uint32_t s, area_count, alloc_count, parity_count; size_t size = 0; /* FIXME Caller should ensure this */ @@ -752,7 +752,9 @@ area_count = stripes; size = sizeof(*ah); - alloc_count = area_count + segtype->parity_devs; + parity_count = (area_count <= segtype->parity_devs) ? 0 : + segtype->parity_devs; + alloc_count = area_count + parity_count; if (segtype_is_raid(segtype) && metadata_area_count) /* RAID has a meta area for each device */ alloc_count *= 2; @@ -787,7 +789,7 @@ else ah->new_extents = 0; ah->area_count = area_count; - ah->parity_count = segtype->parity_devs; + ah->parity_count = parity_count; ah->region_size = region_size; ah->alloc = alloc; ah->area_multiple = _calc_area_multiple(segtype, area_count, stripes); --- LVM2/lib/metadata/raid_manip.c 2012/02/13 11:10:37 1.22 +++ LVM2/lib/metadata/raid_manip.c 2012/02/23 03:57:23 1.23 @@ -493,6 +493,7 @@ { uint32_t s; uint32_t region_size; + uint32_t extents; struct lv_segment *seg = first_seg(lv); const struct segment_type *segtype; struct alloc_handle *ah; @@ -518,8 +519,11 @@ else if (!(segtype = get_segtype_from_string(lv->vg->cmd, "raid1"))) return_0; + extents = (segtype->parity_devs) ? + (lv->le_count / (seg->area_count - segtype->parity_devs)) : + lv->le_count; if (!(ah = allocate_extents(lv->vg, NULL, segtype, 0, count, count, - region_size, lv->le_count, pvs, + region_size, extents, pvs, lv->alloc, parallel_areas))) return_0;
next reply other threads:[~2012-02-23 3:57 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-23 3:57 jbrassow [this message] -- strict thread matches above, loose matches on Subject: below -- 2012-02-23 17:36 jbrassow 2012-02-15 15:18 zkabelac 2012-02-08 13:05 zkabelac 2012-02-01 2:10 agk 2011-10-22 16:42 zkabelac 2011-09-06 18:49 agk 2011-08-18 19:41 jbrassow 2011-08-11 3:29 jbrassow 2011-06-23 14:01 jbrassow 2011-04-09 19:05 zkabelac 2011-01-24 14:19 agk 2011-01-11 17:05 jbrassow 2010-10-14 20:03 jbrassow 2010-04-23 19:27 snitzer 2010-04-09 1:00 agk 2010-03-25 21:19 agk 2010-03-25 2:31 agk 2010-01-08 22:32 jbrassow 2009-05-13 21:29 mbroz 2009-05-13 21:28 mbroz 2009-04-21 14:32 mbroz 2009-04-07 10:20 mbroz 2008-03-28 19:08 wysochanski 2008-01-26 0:25 agk 2008-01-18 22:01 agk 2007-12-20 18:55 agk 2007-08-28 16:14 wysochanski 2007-08-03 21:22 wysochanski 2006-12-13 3:40 agk 2006-10-23 15:54 agk 2006-10-08 12:01 agk 2006-09-11 21:14 agk 2005-11-10 14:45 agk 2005-10-18 13:43 agk 2004-05-05 18:49 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=20120223035724.3768.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).