Debian Bug report logs - #586957
lvm2: miscellaneous improvements for the lvm(8) manpage

version graph

Package: lvm2; Maintainer for lvm2 is Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>; Source for lvm2 is src:lvm2.

Reported by: Christoph Anton Mitterer <calestyo@scientia.net>

Date: Wed, 23 Jun 2010 22:51:01 UTC

Severity: wishlist

Tags: patch

Found in version lvm2/2.02.66-2

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#586957; Package lvm2. (Wed, 23 Jun 2010 22:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
New Bug report received and forwarded. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>. (Wed, 23 Jun 2010 22:51:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: lvm2: miscellaneous improvements for the lvm(8) manpage
Date: Thu, 24 Jun 2010 00:47:49 +0200
[Message part 1 (text/plain, inline)]
Package: lvm2
Version: 2.02.66-2
Severity: wishlist
Tags: patch


Hi.

Attached would be several patches, that (IMHO) improve the lvm(8) manpage:


1) lvm.8.empty_LV.patch
It seems that the current "Where a list of VGs is required but is left empty, a
list  of  all VGs will be substituted." is also true for LVs (checked it with
lvdisplay, which seems to lists all LVs).
If this is true, add the patch, to reflect this in the documentation


2) lvm.8.non-implemented-commands.patch
Aligned the "style" how in the two sections (built-in commands and commands)
unimplemented commands are documented. Just cosmetic of course.
I guess the current style of the commands section is better, built-in
commands list the unimplemented one just as the implemented commands.
Also removed pvdata from the list of unimplemented commands, as this seems
to be an unimplemented built-in command.


3) lvm.8.reordering+pvcreate.patch
It seems that right now, neither built-in commands nor commands are ordered
alphabetically.
The patch orders them in a (IMHO) better way, especially:
First VG-, then PV-, then LV-, then "general"-commands.
In each section I also made some grouping, e.g. commands that do display stuff,
create/remove/rename, resize/extend, etc.
Please check, that (when copy&pasting around) I did not accidentally drop one ;)

Another thing done by the patch: For pvcreate it's hinted (by "etc") that not
only disks and partitions can serve as PV. (e.g. md devices, or dm-crypt, etc.)


4) lvm.8.misc.patch
- Some (IMHO) typos,... please check whether I'm really correct everywhere
(especially the large->larger change).
- Also clarifies, that @ is only used
when referencing tags, not when setting them (i.e. that it's just part of the
string name).
- For the allowed characters in VG/LV names and tags, use the same ordering
in both places they're listed.




Two issues are open, which I do however not know:
1) Should we explicitly mention, that VG/LV names as well as tags are case-
sensitive (or is A-Z a-z) enough.


2) Regarding --alloc
"The cling policy places new extents on the same physical volume as existing
extents in the same stripe of the Logical Volume."

At least I do not understand this:
AFAIK: "For  metadata in  LVM2  format, the stripe size may be a larger power
of 2 but must not exceed the physical extent size."
So it's always that _one_ extent can be divided in one or more stripes, but
_not_ that _one_ stripe can have several extents, right?

But then I don't understand the cling policy description, which no longer makes
sense to me.



Cheers,
Chris.
[lvm.8.empty_LV.patch (text/plain, attachment)]
[lvm.8.misc.patch (text/plain, attachment)]
[lvm.8.reordering+pvcreate.patch (text/plain, attachment)]
[lvm.8.non-implemented-commands.patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#586957; Package lvm2. (Thu, 24 Jun 2010 00:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alasdair G Kergon <agk@redhat.com>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>. (Thu, 24 Jun 2010 00:48:03 GMT) Full text and rfc822 format available.

Message #10 received at 586957@bugs.debian.org (full text, mbox):

From: Alasdair G Kergon <agk@redhat.com>
To: Christoph Anton Mitterer <calestyo@scientia.net>, 586957@bugs.debian.org
Subject: Re: Bug#586957: lvm2: miscellaneous improvements for the lvm(8) manpage
Date: Thu, 24 Jun 2010 01:44:58 +0100
On Thu, Jun 24, 2010 at 12:47:49AM +0200, Christoph Anton Mitterer wrote:
> It seems that the current "Where a list of VGs is required but is left empty, a
> list  of  all VGs will be substituted." is also true for LVs (checked it with
> lvdisplay, which seems to lists all LVs).

Yes
 
> - Also clarifies, that @ is only used
> when referencing tags, not when setting them (i.e. that it's just part of the
> string name).

?
You should always be able to use @ to indicate a tag.
It's optional in places where there's no ambiguity.
 
 

> 1) Should we explicitly mention, that VG/LV names as well as tags are case-
> sensitive (or is A-Z a-z) enough.
 
No harm in doing that - I just assumed people would assume that...

> 2) Regarding --alloc
> "The cling policy places new extents on the same physical volume as existing
> extents in the same stripe of the Logical Volume."

Example:
Given A1 A2  and B1 B2  as two stripes of two extents, and space to be
allocated when extending:  A4 and B4,   cling ensures you get A1 A2 A4  and  B1
B2 B4  instead of A1 A2 B4  and  B1 B2 A4.

"New extent (A4) on the same PV as existing extents (A1 A2) in the same stripe."

 
> AFAIK: "For  metadata in  LVM2  format, the stripe size may be a larger power
> of 2 but must not exceed the physical extent size."
> So it's always that _one_ extent can be divided in one or more stripes, but
> _not_ that _one_ stripe can have several extents, right?
 
"one stripe can have several extents" is imprecise to me.

Alasdair





Information forwarded to debian-bugs-dist@lists.debian.org, Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>:
Bug#586957; Package lvm2. (Thu, 24 Jun 2010 11:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to Debian LVM Team <pkg-lvm-maintainers@lists.alioth.debian.org>. (Thu, 24 Jun 2010 11:39:03 GMT) Full text and rfc822 format available.

Message #15 received at 586957@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Alasdair G Kergon <agk@redhat.com>
Cc: <586957@bugs.debian.org>
Subject: Re: Bug#586957: lvm2: miscellaneous improvements for the lvm(8) manpage
Date: Thu, 24 Jun 2010 11:34:53 +0000
On Thu, 24 Jun 2010 01:44:58 +0100, Alasdair G Kergon <agk@redhat.com>
wrote:
>> It seems that the current "Where a list of VGs is required but is left
>> empty, a
>> list  of  all VGs will be substituted." is also true for LVs (checked
it
>> with
>> lvdisplay, which seems to lists all LVs).
> Yes
k, so that part of the patch already applies.


>> - Also clarifies, that @ is only used
>> when referencing tags, not when setting them (i.e. that it's just part
>> of the
>> string name).
> You should always be able to use @ to indicate a tag.
> It's optional in places where there's no ambiguity.
Well I guess,.. forget that one (and drop the related part of the patch).
In the beginning I had the idea that tags would share the same namespace
as VG/LV names and just therefore you suggest the use of @, which then
would have no special meaning at all.... but it's apparently stupid and
they have separate namespaces, right?


>> 1) Should we explicitly mention, that VG/LV names as well as tags are
>> case-
>> sensitive (or is A-Z a-z) enough.
> No harm in doing that - I just assumed people would assume that...
I think it's rather clear, but you may add it if you want :)
I'm a perfectionist in such things ;)


> "one stripe can have several extents" is imprecise to me.
Ok,.. I still didn't get it:
We have extents, chunks (with snapshots) and stripes (when doing
striping... e.g. -I with lvcreate), right?
So I though, extents are the biggest ranges, and can be further divided in
chunks (for snapshots) and stripes, but not vice versa, e.g. you cannot
have multiple extents in one chunk or stripe.
True so far?
And I further understood that all this must always align, so
extentsize/chunksize = integer AND extentsize/stripesize = integer, right?

So now back to your example:
> Given A1 A2  and B1 B2  as two stripes of two extents, and space to be
> allocated when extending:  A4 and B4,   cling ensures you get A1 A2 A4 
> and  B1
> B2 B4  instead of A1 A2 B4  and  B1 B2 A4.
> 
> "New extent (A4) on the same PV as existing extents (A1 A2) in the same
> stripe."
Which is exactly what?
A (so A1 and A2 together) is an extent? And B (so B1 and B2 together) is
an extent, right?
And A1 and A2 are two stripes within extent A   and  B1 and B2 are two
stripes within extent B, right?
So the stripesize is exactly extentsize/2 ?

Ok,.. now I'm stuck... ^^


Cheers,
Chris.




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 06:29:37 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.