All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alasdair G Kergon <agk@redhat.com>
To: lvm-devel@redhat.com
Subject: Re: LVM2/lib/metadata lv_manip.c
Date: Tue, 7 Aug 2007 13:52:21 +0100	[thread overview]
Message-ID: <20070807125220.GO2064@agk.fab.redhat.com> (raw)
In-Reply-To: <20070806203548.25477.qmail@sourceware.org>

On Mon, Aug 06, 2007 at 08:35:48PM -0000, wysochanski at sourceware.org wrote:
> 	Add support for renaming mirrored LVs.

A patch missing accompanying discussion and analysis.


Did you test this in a cluster?
That's a pre-requisite before this code forms part of any release.

> +static int _rename_single_lv(struct logical_volume *lv, char *new_name)

Should not be _ there.  (Error repeated throughout patch.)
You only need that when it does not follow an explicit log message.

> +static char * sub_lv_name_suffix(const char *lvname)

Remove space after *.
Add _ prefix (static).

[And I don't quite understand the need for this function, and don't
want to see _mimage etc. hard-coded there.]

> + * Returns 0 on failure, 1 on success.

Superfluous comment - it's the default.

> + * If a new name for the sub LV cannot be determined, 1 is returned.

How can that happen?  Why return success if it does?

> + * 'lv_main_old' and 'lv_main_new' are old and new names of the main LV.

So 'sub_lv' is new terminology you're introducing to describe any LV
that is used by any segment of another 'main' LV ?

Currently we have 'toplevel' and 'visible'.
I don't think we need to add 'main'.
I'll ponder what value comes from introducing 'sub_lv'.

And 'lv' suggests struct logical_volume * - but these are const char *
so just call then lv_name_old and lv_name_new.

> +static int _rename_sub_lv(struct cmd_context *cmd,

> +	size_t l;

Use a more-descriptive name.

> +	/* Rename only if the lv has known suffix */
> +	if (!(suffix = sub_lv_name_suffix(lv->name)))
> +		return 1;
> +	/* Make sure that lv->name is exactly a lv_main_old + suffix */
> +	l = suffix - lv->name;
> +	if (strlen(lv_main_old) != l || strncmp(lv->name, lv_main_old, l))
> +		return 1;

The logic here seems a bit twisted.  In what circumstances would those
tests fail and why treat this as success?  And if you are going to
validate the names, then do it properly e.g. why proceed if you find a
mirror log with a suffix 'mimage'?

Today, they should never fail unless there's been a coding bug (or
someone's edited the metadata making it invalid).  Any checks
should be in vg_validate.  It's inconsistent to, in one place, assume
'mimage' was put there by the tools (there's no check on what follows
'mimage') and is a valid name, yet in another place if an invalid name
is encountered, return success.

These are internal LVs with naming under the complete control of LVM2.
If the names became wrong somehow, then issue a log_error by all means but
then correct the names!

Or maybe this is to support future enhancements?  But we haven't yet
discussed how to name internal LVs when they are stacked.

One simple way out perhaps?
  Check if it begins with lv_name_old: if so, replace that part of the
  string with lv_name_new;  if not, log_error and make the entire rename
  fail.  (Add complete name validation to vg_validate, if you wish.)

> +		log_error("Cannot rename hidden LV \"%s\".", lv->name);

New terminology again - please resist and discuss first!
('Internal LV' has been used already.  We might be able to improve on
that, but we should try to avoid using different terminology in different
places.)

> +	/* rename sub LVs */
> +	names[0] = lv->name;
> +	names[1] = new_name;

How do I work out what '0' and '1' mean there?  Please avoid hiding
things like that.  Use a struct there (or enum).

Alasdair
-- 
agk at redhat.com



  reply	other threads:[~2007-08-07 12:52 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06 20:35 LVM2/lib/metadata lv_manip.c wysochanski
2007-08-07 12:52 ` Alasdair G Kergon [this message]
2007-08-07 12:56   ` Alasdair G Kergon
2007-08-07 21:15   ` Jun'ichi Nomura
  -- strict thread matches above, loose matches on Subject: below --
2007-08-07 16:57 wysochanski
2007-08-07 18:55 wysochanski
2007-08-08 18:00 wysochanski
2007-08-09  2:46 ` jorge alberto garcia gonzalez
2007-08-09  2:52 ` jorge alberto garcia gonzalez
2007-11-04 16:28 agk
2008-01-16 20:00 agk
2009-01-06 17:24 mbroz
2009-06-01 14:23 mbroz
2009-06-06 16:37 mbroz
2010-01-08 23:06 jbrassow
2010-01-10 20:44 snitzer
2010-01-13  1:51 snitzer
2010-01-13  1:52 snitzer
2010-01-14 10:08 zkabelac
2010-01-14 10:09 zkabelac
2010-01-14 10:17 zkabelac
2010-01-20 21:53 snitzer
2010-02-17 23:36 snitzer
2010-03-31 20:26 agk
2010-04-01 12:29 agk
2010-04-01 13:58 agk
2010-04-02  1:35 agk
2010-04-08  0:52 agk
2010-04-08  0:56 agk
2011-03-25 22:02 jbrassow
2011-03-25 22:10 ` Zdenek Kabelac
2011-06-06 12:08 agk
2011-08-05  9:21 prajnoha
2011-08-10 16:44 jbrassow
2011-08-19 16:41 agk
2011-08-19 22:55 agk
2011-09-06 15:39 agk
2011-09-16 11:59 zkabelac
2011-09-16 12:12 zkabelac
2011-09-16 18:39 jbrassow
2011-10-03 18:43 zkabelac
2011-10-20 10:35 zkabelac
2011-10-21  9:55 zkabelac
2011-10-22 16:46 zkabelac
2011-10-22 16:48 zkabelac
2011-10-28 20:18 zkabelac
2011-10-28 20:29 zkabelac
2011-10-30 22:02 zkabelac
2011-11-03 14:56 zkabelac
2011-11-03 15:46 zkabelac
2011-11-04 22:45 zkabelac
2011-11-07 13:54 agk
2011-11-10 12:39 zkabelac
2011-11-10 12:42 zkabelac
2011-11-10 12:42 zkabelac
2011-11-12 22:51 zkabelac
2011-11-12 22:52 zkabelac
2011-11-12 22:53 zkabelac
2011-11-15 17:23 zkabelac
2011-11-15 17:29 zkabelac
2012-01-19 15:39 zkabelac
2012-01-24 14:15 mbroz
2012-01-24 14:54 agk
2012-01-25  8:57 zkabelac
2012-01-25  9:02 zkabelac
2012-01-25  9:14 zkabelac
2012-01-25  9:15 zkabelac
2012-01-25 11:27 zkabelac
2012-01-26 21:39 zkabelac
2012-02-01  2:11 agk
2012-02-12 21:37 agk
2012-02-28 10:08 zkabelac
2012-03-01 10:09 zkabelac
2012-03-04 15:57 zkabelac
2012-05-11 15:26 agk
2012-05-11 15:32 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=20070807125220.GO2064@agk.fab.redhat.com \
    --to=agk@redhat.com \
    --cc=lvm-devel@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.