[linux-lvm] lvextend does not change/fix stripes & stripesize for the whole LV?

[lejeczek]

right?
Or it does?
From man pages my understanding is - it does not, an
expression "the extension" is used there.

If I have a LV with 2 stripes and 64KiB stripesizes, then
adding two more stripes, like this:

$ lvextend h300Int1/0 -i 2 -I 16 /dev/sd3 /dev/sd4 (if it
was to succeed)

will change the LV into 4 stripes LV, but what would
happened to stripesize(s)?

many thanks,
L.

[Zdenek Kabelac]

Post by lejeczek
right?
Or it does?
From man pages my understanding is - it does not, an expression "the
extension" is used there.
If I have a LV with 2 stripes and 64KiB stripesizes, then adding two more
$ lvextend h300Int1/0 -i 2 -I 16 /dev/sd3 /dev/sd4 (if it was to succeed)
will change the LV into 4 stripes LV, but what would happened to stripesize(s)?

Hi

At this moment lvm2 supports extension only of the same types.
So extended/added segment will have some 'geometry' as the last/previous
segment of your extended LV.

So if you do not add any 'striping' parameters - they will be automatically
detected from LV, if you add them - they will be compared and in case of
mismatch operation will be rejected.

Also if the allocation policy and free space in VG allows - extension will try
first to extend existing segment before allocating new space somewhere else in VG.

Regards

Zdenek

[lejeczek]

Post by Zdenek Kabelac

Post by lejeczek
right?
Or it does?
From man pages my understanding is - it does not, an
expression "the
extension" is used there.
If I have a LV with 2 stripes and 64KiB stripesizes, then
adding two more
$ lvextend h300Int1/0 -i 2 -I 16 /dev/sd3 /dev/sd4 (if it
was to succeed)
will change the LV into 4 stripes LV, but what would
happened to stripesize(s)?

Hi
At this moment lvm2 supports extension only of the same
types.
So extended/added segment will have some 'geometry' as the
last/previous segment of your extended LV.
So if you do not add any 'striping' parameters - they will
be automatically detected from LV, if you add them - they
will be compared and in case of mismatch operation will be
rejected.
Also if the allocation policy and free space in VG allows
- extension will try first to extend existing segment
before allocating new space somewhere else in VG.
Regards
Zdenek

many! thanks
may I share a comment - inasmuch as man pages for lvm are
really good, there are places where some bits are missing.
Take LVEXTEND, it speaks of --alloc but does not elaborate
on it at all.
Also says:
--use-policies Resizes the logical volume
according to configured policy. See lvm.conf
But I failed to find it there in lvm.conf.

Would be great to have man pages completed with these
missing bits. It's rhel 7.3, lvm2-2.02.166-1.el7_3.2.x86_64

Ca I also ask you - reason I'm hoping I could downsize the
stripesize is for I understand that with higher number of
stripes stripesize could shrink so data(smaller files) would
go to more(all?) stripes(increasing transfers speeds, phy
devs are all SSDs in my case). Is my logic false here?

And if it is not, would then creating a second LV(the same
VG) with different(smaller) stripesize, then moving data
over there, then removing the first LV and finally extending
that "second" LV be a good, a correct way?

b.w.
L

Post by Zdenek Kabelac
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[David Teigland]

may I share a comment - inasmuch as man pages for lvm are really good, there
are places where some bits are missing.
Would be great to have man pages completed with these missing bits. It's
rhel 7.3, lvm2-2.02.166-1.el7_3.2.x86_64

The lvm man pages have just been reworked in the upstream git, and any
feedback would be welcome (they are still being polished). They are now
generated, along with the command help output, from a formal set of
"command definitions". This defines commands recognized by lvm, their
syntax, accepted options, and is the source man/help are generated from.
The code, help output and man pages will always be in sync because it is
all from one place.

Dave

[lejeczek]

Post by Zdenek Kabelac

Post by lejeczek
right?
Or it does?
From man pages my understanding is - it does not, an
expression "the
extension" is used there.
If I have a LV with 2 stripes and 64KiB stripesizes, then
adding two more
$ lvextend h300Int1/0 -i 2 -I 16 /dev/sd3 /dev/sd4 (if it
was to succeed)
will change the LV into 4 stripes LV, but what would
happened to stripesize(s)?

Hi
At this moment lvm2 supports extension only of the same
types.
So extended/added segment will have some 'geometry' as the
last/previous segment of your extended LV.
So if you do not add any 'striping' parameters - they will
be automatically detected from LV, if you add them - they
will be compared and in case of mismatch operation will be
rejected.
Also if the allocation policy and free space in VG allows
- extension will try first to extend existing segment
before allocating new space somewhere else in VG.
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

now actually trying in practice:
an VG(just extended by /dev/sdf):

--- Physical volumes ---
PV Name /dev/sdd
PV UUID j0tyRo-k0EV-uvXv-8F3K-fQpc-LcyE-twIZs1
PV Status allocatable
Total PE / Free PE 250390 / 0

PV Name /dev/sde
PV UUID jF0NlQ-Q4zd-zWr2-s0nb-kBzc-SmYj-SrgOnW
PV Status allocatable
Total PE / Free PE 250390 / 0

PV Name /dev/sdc
PV UUID NoxH5O-6nvb-thAR-cHM6-VRTJ-gJyn-HK7y0c
PV Status allocatable
Total PE / Free PE 250390 / 0

PV Name /dev/sdf
PV UUID 27jeEj-frTR-wVQB-7Sg5-MZ6g-1eSV-RQuU8a
PV Status allocatable
Total PE / Free PE 250390 / 250390

all these fail:
$ lvextend -v -i 4 -l+100%free dellH200.InternalB/0
$ lvextend -v -i 4 -l+100%pv dellH200.InternalB/0 /dev/sdf
$ lvextend -i 4 -l 100%vg dellH200.InternalB/0

is there a problem?