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;


             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: 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).