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-exported.h lib/meta ... Date: Wed, 02 Sep 2009 21:39:00 -0000 [thread overview] Message-ID: <20090902213930.18460.qmail@sourceware.org> (raw) CVSROOT: /cvs/lvm2 Module name: LVM2 Changes by: wysochanski@sourceware.org 2009-09-02 21:39:29 Modified files: lib/metadata : metadata-exported.h metadata.c liblvm : lvm_vg.c tools : vgremove.c Log message: Split vg_remove_single into 2 functions - the second part commits to disk. Split vg_remove_single into vg_remove_check (mandatory checks before vgremove) and vg_remove (do actual remove by committing to disk). In liblvm, we'd like to provide an consistent API that allows multiple changes in memory, then let lvm_vg_write() control the commit to disk. In some cases (for example, lvresize calls fsadm) this may not be possible. However, since we are using an object model and dividing things into small operations, the most logical model seems to be the lvm_vg_write model, and handling the special cases as they arrive. So as best as possible we move towards this end. A possible optimization would be to consolidate vg_remove (committing) code with vgreduce code. A second possible optimization is making vgreduce of the last device equivalent to vgremove. Today, lvm_vg_reduce fails if vgreduce is called with the last device, but from an object model perspective we could view this as equivalent to vgremove and allow it. My gut feel is we do not want to do this though. Author: Dave Wysochanski <dwysocha@redhat.com> Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata-exported.h.diff?cvsroot=lvm2&r1=1.108&r2=1.109 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.c.diff?cvsroot=lvm2&r1=1.280&r2=1.281 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/liblvm/lvm_vg.c.diff?cvsroot=lvm2&r1=1.26&r2=1.27 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/tools/vgremove.c.diff?cvsroot=lvm2&r1=1.54&r2=1.55 --- LVM2/lib/metadata/metadata-exported.h 2009/09/02 21:39:07 1.108 +++ LVM2/lib/metadata/metadata-exported.h 2009/09/02 21:39:29 1.109 @@ -442,7 +442,8 @@ struct volume_group *vg_create(struct cmd_context *cmd, const char *vg_name); int vg_remove_mdas(struct volume_group *vg); -int vg_remove_single(struct volume_group *vg); +int vg_remove_check(struct volume_group *vg); +int vg_remove(struct volume_group *vg); int vg_rename(struct cmd_context *cmd, struct volume_group *vg, const char *new_name); int vg_extend(struct volume_group *vg, int pv_count, char **pv_names); --- LVM2/lib/metadata/metadata.c 2009/09/02 21:39:07 1.280 +++ LVM2/lib/metadata/metadata.c 2009/09/02 21:39:29 1.281 @@ -468,12 +468,9 @@ return 1; } -int vg_remove_single(struct volume_group *vg) +int vg_remove_check(struct volume_group *vg) { - struct physical_volume *pv; - struct pv_list *pvl; unsigned lv_count; - int ret = 1; if (vg_read_error(vg) || vg_missing_pv_count(vg)) { log_error("Volume group \"%s\" not found, is inconsistent " @@ -497,6 +494,15 @@ if (!archive(vg)) return 0; + return 1; +} + +int vg_remove(struct volume_group *vg) +{ + struct physical_volume *pv; + struct pv_list *pvl; + int ret = 1; + if (!lock_vol(vg->cmd, VG_ORPHANS, LCK_VG_WRITE)) { log_error("Can't get lock for orphan PVs"); return 0; --- LVM2/liblvm/lvm_vg.c 2009/08/13 12:16:45 1.26 +++ LVM2/liblvm/lvm_vg.c 2009/09/02 21:39:29 1.27 @@ -153,7 +153,10 @@ if (!vg_check_write_mode(vg)) return -1; - if (!vg_remove_single(vg)) + if (!vg_remove_check(vg)) + return -1; + + if (!vg_remove(vg)) return -1; return 0; } --- LVM2/tools/vgremove.c 2009/07/14 19:37:18 1.54 +++ LVM2/tools/vgremove.c 2009/09/02 21:39:29 1.55 @@ -44,7 +44,10 @@ return ECMD_FAILED; } - if (!vg_remove_single(vg)) + if (!vg_remove_check(vg)) + return ECMD_FAILED; + + if (!vg_remove(vg)) return ECMD_FAILED; return ECMD_PROCESSED;
next reply other threads:[~2009-09-02 21:39 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-09-02 21:39 wysochanski [this message] -- strict thread matches above, loose matches on Subject: below -- 2011-02-21 12:29 prajnoha 2010-10-12 16:41 mornfall 2010-06-30 20:03 agk 2010-06-30 18:03 wysochanski 2010-06-29 21:32 wysochanski 2010-06-28 20:40 wysochanski 2010-02-24 18:15 wysochanski 2010-02-24 18:15 wysochanski 2010-02-14 3:21 wysochanski 2010-02-14 3:21 wysochanski 2009-11-01 20:05 wysochanski 2009-11-01 19:51 wysochanski 2009-10-31 17:30 wysochanski 2009-10-05 20:03 wysochanski 2009-10-05 20:02 wysochanski 2009-10-01 1:04 agk 2009-09-14 15:45 wysochanski 2009-09-02 21:39 wysochanski 2009-07-28 15:14 wysochanski 2009-07-28 13:17 wysochanski 2009-07-26 2:34 wysochanski 2009-07-26 1:53 wysochanski 2009-07-15 5:50 mornfall 2009-07-14 2:15 wysochanski 2009-07-10 20:07 wysochanski 2009-07-10 20:05 wysochanski 2009-07-09 10:09 wysochanski 2009-07-09 10:08 wysochanski 2009-07-09 10:07 wysochanski 2009-07-09 10:06 wysochanski 2009-07-09 10:04 wysochanski 2009-07-09 10:03 wysochanski 2009-07-08 14:33 wysochanski 2009-07-01 17:01 wysochanski 2008-06-24 20:10 wysochanski 2008-01-16 19:54 wysochanski 2008-01-15 22:56 wysochanski 2007-12-22 2:13 agk 2007-11-15 22:11 agk 2007-07-23 21:03 wysochanski
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=20090902213930.18460.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).