Re: Possible bug in mirror target

["Bryn M. Reeves" <bmr@redhat.com>]

On Wed, Feb 13, 2019 at 07:08:40PM +0100, Zdenek Kabelac wrote:
> Dne 13. 02. 19 v 16:01 Bryn M. Reeves napsal(a):
> > On Wed, Feb 13, 2019 at 03:21:52PM +0100, Zdenek Kabelac wrote:
> > > If you have this free space it's surely not a bad thing - but there
> > > are many cases, you can get any free space - majority of filesystems
> > > does not support shrinking - so the only 'free' space you can
> > > get is by adding new storage to VG - again quite limiting factor.
> > 
> > Probably obvious to many, but if you find yourself in this situation
> > using the Red Hat / Fedora default layout created by Anaconda, the
> > easiest solution is normally to "steal" one extent from the auto-
> > configured swap LV, and donate it to the mirror conversion:
> > 
> >    # swapoff -a
> >    # lvresize -l -1 rhel/swap
> >    # mkswap /dev/rhel/swap
> >    # swapon -a
> >    # lvchange -m1 ...
> > 
> > This will always work with the automatic layouts provided by those
> > distros.
> 
> Just to further clear this - yeah - stealing 1 extent this way 'mostly'
> temporarily works, however for conversion to 'raid' - the rule should be,
> that log/metadata device for each leg should be co-located on the same
> physical device as the leg itself - clearly storing multiple or all metadata
> devices on 1 physical device will not have required purpose - although as

That's exactly what those steps do (I used them two days ago to verify
an RHBZ). You steal the extent from the system PV that Anaconda originally
created the volume group on, providing a rmeta log on the same device as
the image volume.

Extra steps would be needed to coerce the logs onto the same devices:

  rhel-root (253:4)
   ├─rhel-root_rimage_1 (253:3)
   │  └─ (252:17)
   ├─rhel-root_rmeta_1 (253:2)
   │  └─ (252:17)
   ├─rhel-root_rimage_0 (253:1)
   │  └─ (252:2)
   └─rhel-root_rmeta_0 (253:0)
      └─ (252:2)

You obviously need to also provide sufficient space in any new PV to allow
for the extra log extent, but that shouldn't be either surprising or
difficult.

Regards,
Bryn.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel