[cinder] lvm_mirrors option seems to be broken
lehrer at gmail.com
Tue Jul 30 16:45:20 UTC 2019
Final suggestion: on my system, lvm seems to work best with the
"--type raid10" option.
Perhaps a cinder.conf option for lvm_type=raid10 would be useful?
raid1 too? I am seeing this warning from lvcreate quite a lot, so
something needs to change fairly soon:
WARNING: Log type "mirrored" is DEPRECATED and will be removed in the
future. Use RAID1 LV or disk log instead.
On Tue, Jul 30, 2019 at 10:08 AM Mark Lehrer <lehrer at gmail.com> wrote:
> OK things aren't quite as broken as I thought at first.
> It looks like lvm_type needs to be set to default (instead of thin),
> otherwise the lvm_mirrors option causes havoc. Maybe a warning in the
> logs about incompatible options would save the next person some time.
> On Tue, Jul 30, 2019 at 9:01 AM Mark Lehrer <lehrer at gmail.com> wrote:
> > I have 4 fast nvme targets that I want to combine using RAID 10 and
> > use with cinder-lvm.
> > Unfortunately, lvm+mdadm is breaking all of my writes down to 4K --
> > without even increasing the queue depth to match. SSDs hate this
> > workload.
> > I tried bypassing mdadm by seting up LVM RAID10 by hand and got
> > roughly a 10x increase in performance, so I definitely want to use
> > this if possible.
> > However, it looks like maybe the lvm_mirrors code hasn't been kept up
> > to date. I ran into two main problems trying to use it:
> > 1) The algorithm to calculate free space is broken and always returns
> > 0. This means that the scheduler will never even try to use this pool
> > 2) Thin provisioning is getting in the way... with lvm_mirrors enabled
> > the code is apparently trying to create a new LV on top of the thin
> > provisioned LV... and it is using an lvcreate option that appears to
> > be deprecated (--mirrorlog mirrored)
> > I expect I can fix #1, but what is the best way to handle #2? I was
> > thinking that the easiest fix would be to use the mirror options when
> > the thin LV is created, though I haven't tried it by hand yet to see
> > if it works. The advantage here is that this is a one-time setting
> > and the code path to create individual volumes wouldn't need to check
> > lvm_mirrors at all.
> > Thanks,
> > Mark
More information about the openstack-discuss