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

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

[lejeczek]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 653 bytes --]

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

[Zdenek Kabelac]

Dne 4.3.2017 v 14:58 lejeczek napsal(a):
> 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)?
>

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

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

[lejeczek]

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]



On 06/03/17 09:47, Zdenek Kabelac wrote:
> Dne 4.3.2017 v 14:58 lejeczek napsal(a):
>> 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)?
>>
>
> 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

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


[-- Attachment #2: Type: text/html, Size: 3685 bytes --]

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

[David Teigland]

On Mon, Mar 06, 2017 at 10:56:49AM +0000, lejeczek wrote:
> 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

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

[lejeczek]

On 06/03/17 09:47, Zdenek Kabelac wrote:
> Dne 4.3.2017 v 14:58 lejeczek napsal(a):
>> 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)?
>>
>
> 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
> linux-lvm@redhat.com
> 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?