(In reply to Jonathan Earl Brassow from comment #0)
> Note how shorthand option work and longhand does not.
> 
> [root@bp-01 ~]# lvcreate -L 5G -n lv vg
>   Logical volume "lv" created.
> [root@bp-01 ~]# devices vg
>   LV   Attr       Cpy%Sync Devices
>   lv   -wi-a-----          /dev/sdb1(0)
> [root@bp-01 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror
> --stripes 2
>   Command does not accept option: --stripes 2.
> [root@bp-01 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror
> -i 2
>   Logical volume vg/lv being converted.
>   vg/lv: Converted: 0.08%

Please scratch the above and note on RHEL6.9 (and probably 7.3):
[root@bp-02 ~]# lvcreate -L 5G -n lv vg
  Logical volume "lv" created.
[root@bp-02 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror --stripes 2
  Using default stripesize 64.00 KiB.
  vg/lv: Converted: 0.2%
^C
[root@bp-02 ~]# devices  vg
  LV            Attr       Cpy%Sync Devices
  lv            mwi-a-m--- 32.19    lv_mimage_0(0),lv_mimage_1(0)
  [lv_mimage_0] Iwi-aom---          /dev/sdb1(0)
  [lv_mimage_1] Iwi-aom---          /dev/sdd1(0),/dev/sde1(0)

but on 7.5:
[root@bp-01 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror --stripes 2
  Command does not accept option: --stripes 2.

Unfortunately, after looking into the feasibility of this, it is not possible to support this behavior predictably.  We will have to steer users to the available methods and methods coming in the future:

> We do have prototype code that will allow conversion from one type to any other type (linear <-> RAIDx) through an online mirroring action.  It is not an in-place reshape (technically, a “take-over”) and would require extra disks.  This solution is not currently scheduled to land, but I can see it in the early timeframe of the next major release.

> We also have the ability to use ‘lvconvert’ to change one LV type to another (e.g. RAID1 to RAID5).  The process of going from linear to striped is not a direct one, but it can be done.  We could probably improve our “coaching” for users in this area.  This solution uses an “in-place” conversion and does not require a full set of extra devices.

Also see bug 1494135 and bug 1483530.

As far as I know this command is still supposed to be disallowed.  It has been discussed at length, but I have not followed the reasons why.  If something has changed, and the code can handle this correctly, then please let me know and I will update the command definitions to permit it.

Is this bug related to the recent fix for https://bugzilla.redhat.com/show_bug.cgi?id=1720705 ?

(In reply to Jonathan Earl Brassow from comment #8)
> Is this bug related to the recent fix for
> https://bugzilla.redhat.com/show_bug.cgi?id=1720705 ?

Yes, the fix as of bz#1720705 also fixes this one.

(In reply to David Teigland from comment #7)
> Also see bug 1494135 and bug 1483530.

I disagree, both referenced bugs are about RAID1 volumes. For RAID1 volumes there exists a conversion path to RAID0.

Mirrors apparently worked fine in this scenario in RHEL-6 and RHEL-7 up to RHEL-7.4.
And it is this functionality removed in RHEL-7.5 the customer wants to use.

> As far as I know this command is still supposed to be disallowed.  It has
> been discussed at length, but I have not followed the reasons why.  If
> something has changed, and the code can handle this correctly, then please
> let me know and I will update the command definitions to permit it.

The discussion was rather philosophical, Not single technical argument why it should not be allowed.

The only issue raised were:

- we (will) have raids
- this creates asymmetrical mirror with one leg linear and other one stripe, which is useless, it is inferior raid01 instead of much better raid10.
- what is requires should be called "duplication/replication" not mirror/raid1.

The RAIDs may be superior, but as Nikhil pointed out linear to stripe conversion through raids takes several steps, requires more space, and writes 3 to 4 times the amount of data the "duplication" uses.

1. convert to raid1 (copying 100% of data):

[root@r-el77conv2raid0 ~]# lvconvert --type raid1 -m 1 vgtest/lv1
Are you sure you want to convert linear LV vgtest/lv1 to raid1 with 2 images enhancing resilience? [y/n]: y
  Logical volume vgtest/lv1 successfully converted.

2. conversion to raid5_n with 2 legs - one for data and one for parity IIUC, writing 100% of data again:
Perhaps the conversion to raid1 first is ... superficial?

[root@r-el77conv2raid0 ~]# lvconvert --type raid0 -i 2 vgtest/lv1
  Using default stripesize 64.00 KiB.
  Replaced LV type raid0 with possible type raid5_n.
  Repeat this command to convert to raid0 after an interim conversion has finished.
  --stripes not allowed for LV vgtest/lv1 when converting from raid1 to raid5_n.
Are you sure you want to convert raid1 LV vgtest/lv1 to raid5_n type? [y/n]: y
  Logical volume vgtest/lv1 successfully converted.
[root@r-el77conv2raid0 ~]# lvs -a
  LV             VG              Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root           vg_stacker_ihD9 -wi-ao----   6.00g                                                    
  lv1            vgtest          rwi-a-r--- 100.00m                                    100.00          
  [lv1_rimage_0] vgtest          iwi-aor--- 100.00m                                                    
  [lv1_rimage_1] vgtest          iwi-aor--- 100.00m                                                    
  [lv1_rmeta_0]  vgtest          ewi-aor---   4.00m                                                    
  [lv1_rmeta_1]  vgtest          ewi-aor---   4.00m                                                    

3. upconverting the raid5_n to 3 stripes, writing another 100 or 200% of data:

[root@r-el77conv2raid0 ~]# lvconvert --type raid0 -i 2 vgtest/lv1
  Using default stripesize 64.00 KiB.
  Converting raid5_n LV vgtest/lv1 to 3 stripes first.
  Replaced LV type raid0 with possible type raid5_n.
  Repeat this command to convert to raid0 after an interim conversion has finished.
  WARNING: Adding stripes to active logical volume vgtest/lv1 will grow it from 25 to 50 extents!
  Run "lvresize -l25 vgtest/lv1" to shrink it or use the additional capacity.
Are you sure you want to add 1 images to raid5_n LV vgtest/lv1? [y/n]: y
  Logical volume vgtest/lv1 successfully converted.

Here comes the problem:
>  WARNING: Adding stripes to active logical volume vgtest/lv1 will grow it from 25 to 50 extents!
>  Run "lvresize -l25 vgtest/lv1" to shrink it or use the additional capacity.

So the conversion requires three times the space.
Q: Is user supposed to shrink it first of after the conversion?
A: After. The size before would not change. It changes during upconversion.

4. finally converting to raid0....

I do not think the customer requires in-place conversions. And certainly not in-place conversion which requires 3 times the space than mere "duplication" which would requires only twice. Not in-place conversion which requires 4 steps instead of one (well two...). And copies 3-4 times the amount of data written by duplication.

Even if in-place conversion would be a better solution, that will still not work e.g. as active/active volume in cluster.

(In reply to Marian Csontos from comment #10)
> (In reply to David Teigland from comment #7)
> > Also see bug 1494135 and bug 1483530.
> 
> I disagree, both referenced bugs are about RAID1 volumes. For RAID1 volumes
> there exists a conversion path to RAID0.
> 
> Mirrors apparently worked fine in this scenario in RHEL-6 and RHEL-7 up to
> RHEL-7.4.
> And it is this functionality removed in RHEL-7.5 the customer wants to use.

Now that the regression removing 'mirror' with 'striped' legs is fixed,
we got it back for the customer.

> 
> > As far as I know this command is still supposed to be disallowed.  It has
> > been discussed at length, but I have not followed the reasons why.  If
> > something has changed, and the code can handle this correctly, then please
> > let me know and I will update the command definitions to permit it.
> 
> The discussion was rather philosophical, Not single technical argument why
> it should not be allowed.
> 
> The only issue raised were:
> 
> - we (will) have raids
> - this creates asymmetrical mirror with one leg linear and other one stripe,
> which is useless, it is inferior raid01 instead of much better raid10.
> - what is requires should be called "duplication/replication" not
> mirror/raid1.
> 
> The RAIDs may be superior, but as Nikhil pointed out linear to stripe
> conversion through raids takes several steps, requires more space, and
> writes 3 to 4 times the amount of data the "duplication" uses.
> 
> 1. convert to raid1 (copying 100% of data):
> 
> [root@r-el77conv2raid0 ~]# lvconvert --type raid1 -m 1 vgtest/lv1
> Are you sure you want to convert linear LV vgtest/lv1 to raid1 with 2 images
> enhancing resilience? [y/n]: y
>   Logical volume vgtest/lv1 successfully converted.
> 
> 2. conversion to raid5_n with 2 legs - one for data and one for parity IIUC,
> writing 100% of data again:
> Perhaps the conversion to raid1 first is ... superficial?

May be hidden in case we eventually support multi-step conversions via lvmpolld
but for the time being, that's how things work technically
(linear -> 2-legged raid1 upconvert -> raid5_n -> more stripes -> raid0).

> 
> [root@r-el77conv2raid0 ~]# lvconvert --type raid0 -i 2 vgtest/lv1
>   Using default stripesize 64.00 KiB.
>   Replaced LV type raid0 with possible type raid5_n.
>   Repeat this command to convert to raid0 after an interim conversion has
> finished.
>   --stripes not allowed for LV vgtest/lv1 when converting from raid1 to
> raid5_n.
> Are you sure you want to convert raid1 LV vgtest/lv1 to raid5_n type? [y/n]:
> y
>   Logical volume vgtest/lv1 successfully converted.
> [root@r-el77conv2raid0 ~]# lvs -a
>   LV             VG              Attr       LSize   Pool Origin Data%  Meta%
> Move Log Cpy%Sync Convert
>   root           vg_stacker_ihD9 -wi-ao----   6.00g                         
> 
>   lv1            vgtest          rwi-a-r--- 100.00m                         
> 100.00          
>   [lv1_rimage_0] vgtest          iwi-aor--- 100.00m                         
> 
>   [lv1_rimage_1] vgtest          iwi-aor--- 100.00m                         
> 
>   [lv1_rmeta_0]  vgtest          ewi-aor---   4.00m                         
> 
>   [lv1_rmeta_1]  vgtest          ewi-aor---   4.00m                         
> 
> 
> 3. upconverting the raid5_n to 3 stripes, writing another 100 or 200% of
> data:

Upconverting and reshaping to 3 stripes total with raid requires an interim 300%
and a final 200% space for the striped/raid0 of the initial linear LV.

OTOH, the reintroduced 'mirror' functionality only requires an interim 200%
whilst keeping the same size of the initial linear LV for the final 'striped' one.

> 
> [root@r-el77conv2raid0 ~]# lvconvert --type raid0 -i 2 vgtest/lv1
>   Using default stripesize 64.00 KiB.
>   Converting raid5_n LV vgtest/lv1 to 3 stripes first.
>   Replaced LV type raid0 with possible type raid5_n.
>   Repeat this command to convert to raid0 after an interim conversion has
> finished.
>   WARNING: Adding stripes to active logical volume vgtest/lv1 will grow it
> from 25 to 50 extents!
>   Run "lvresize -l25 vgtest/lv1" to shrink it or use the additional capacity.
> Are you sure you want to add 1 images to raid5_n LV vgtest/lv1? [y/n]: y
>   Logical volume vgtest/lv1 successfully converted.
> 
> Here comes the problem:
> >  WARNING: Adding stripes to active logical volume vgtest/lv1 will grow it from 25 to 50 extents!
> >  Run "lvresize -l25 vgtest/lv1" to shrink it or use the additional capacity.
> 
> So the conversion requires three times the space.
> Q: Is user supposed to shrink it first of after the conversion?
> A: After. The size before would not change. It changes during upconversion.

Well, user could shrink before in case the content may shrink (e.g. resizefs if at all possible).

> 
> 4. finally converting to raid0....
> 
> I do not think the customer requires in-place conversions. And certainly not
> in-place conversion which requires 3 times the space than mere "duplication"
> which would requires only twice. Not in-place conversion which requires 4
> steps instead of one (well two...). And copies 3-4 times the amount of data
> written by duplication.

This particular customer does not because he asks for getting functionality
back he's already used to.

My shelved dup/undup raid support for lvm is about avoiding the additional space
requirements involved with reshaping by allowing e.g. arbitrary raid* legs underneath
an N-legged top-level raid1 and being able to drop any fo them keeping the final intended layout.

> 
> Even if in-place conversion would be a better solution, that will still not
> work e.g. as active/active volume in cluster.

Indeed.

lvm2 commit IDs:
master 1b63a219f4f9d7f2f6c5086375b96c3bd892a1a0
stable-2.02 e3c8cebd87f9bd7591529f3d65783cc6f1fd3f92

Marking verified in the latest rpms. 

lvm2-2.02.185-2.el7.x86_64

[root@hayes-01 ~]# lvs -a -o +devices
  LV   VG Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices     
  lv   vg -wi-a----- 5.00g                                                     /dev/sdb1(0)
[root@hayes-01 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror --stripes 2
  Command does not accept option: --stripes 2.


lvm2-2.02.186-3.el7.x86_64

[root@hayes-01 ~]# lvconvert --mirrors 1 vg/lv --mirrorlog core --type mirror --stripes 2
  Using default stripesize 64.00 KiB.
  Logical volume vg/lv being converted.
  vg/lv: Converted: 0.16%
  vg/lv: Converted: 27.50%
  vg/lv: Converted: 55.08%
  vg/lv: Converted: 82.66%
  vg/lv: Converted: 100.00%
[root@hayes-01 ~]# lvs -a -o +devices
  LV            VG Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices                      
  lv            vg mwi-a-m--- 5.00g                                    100.00           lv_mimage_0(0),lv_mimage_1(0)
  [lv_mimage_0] vg iwi-aom--- 5.00g                                                     /dev/sdb1(0)                 
  [lv_mimage_1] vg iwi-aom--- 5.00g                                                     /dev/sdc1(0),/dev/sdd1(0)

FYI - up conversion will only work if the extent total is divisible by 2. If it's an odd number, it will not work.

TAKEOVER: lvconvert --force --yes -R 512.00k -m 2 --stripes 2 --type mirror centipede2/takeover
  Number of extents requested (725) needs to be divisible by 2.
  Unable to allocate extents for mirror(s).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1129