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.

Yes

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

No harm in doing that - I just assumed people would assume that...
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."

"one stripe can have several extents" is imprecise to me.

Alasdair

it
k, so that part of the patch already applies.
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?
I think it's rather clear, but you may add it if you want :)
I'm a perfectionist in such things ;)
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:
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.