All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: Zdenek Kabelac <zkabelac@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] lvmcache with vdo - inconsistent block size
Date: Wed, 16 Sep 2020 00:32:06 +0200	[thread overview]
Message-ID: <056d2d5dd9a7846a56971ce5f4cb3537@assyoma.it> (raw)
In-Reply-To: <5070f4fa-81ad-9c9a-b0a7-8d5463ea09d3@redhat.com>

Il 2020-09-15 20:34 Zdenek Kabelac ha scritto:
> Dne 14. 09. 20 v 23:44 Gionatan Danti napsal(a):
>> Hi all,
>> I am testing lvmcache with VDO and I have issue with devices block 
>> size.
>> 
>> The big & slow VDO device is on top of a 4-disk MD RAID 10 device 
>> (itself on top of dm-integrity). Over the VDO device I created a 
>> thinpool and a thinvol [1]. When adding the cache device to the volume 
>> group via vgextend, I get an error stating "Devices have inconsistent 
>> logical block sizes (4096 and 512)." [2]
>> 
>> Now, I know why the error shows and what i means. However, I don't 
>> know how to force the cache device to act as a 4k sector device, 
>> and/if this is really required to cache a VDO device.
>> 
>> My current workaround is to set VDO with --emulate512=enabled, but 
>> this can be suboptimal and it is not recommended.
>> 
>> Any idea on what I am doing wrong?
> 
> Hi
> 
> LVM currently does not support mixing devices of different sector sizes 
> within
> a single VG as it brings lot of troubles we have not yet clear vision 
> what
> to do with all of them.

Hi Zdenek, yes, I understand. What surprised me is that lvmvdo *can* be 
combined with caching, and it does not suffer from this issue. Can you 
elaborate on why it works in this case?

> Also this combination of provisioned devices is not advised - since
> you are combining 2 kind of devices on top of each other and it can be
> a big problem
> to solve recovery case.

True.

> On lvm2 side we do not allow to use 'VDO LV' as backend for thin-pool 
> device.

I noticed it. However, from what I can read on RedHat docs, thinpool 
over VDO device should be perfectly fine (the other way around, not so 
much).

> So ATM it's on a user to solve all the possible scenarios that may 
> appear on
> such device stack.
> 
> Zdenek

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

  reply	other threads:[~2020-09-15 22:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 21:44 [linux-lvm] lvmcache with vdo - inconsistent block size Gionatan Danti
2020-09-15 18:34 ` Zdenek Kabelac
2020-09-15 22:32   ` Gionatan Danti [this message]
2020-09-17 19:27     ` Zdenek Kabelac
2020-09-17 21:41       ` Gionatan Danti
2020-09-17 21:46         ` Zdenek Kabelac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=056d2d5dd9a7846a56971ce5f4cb3537@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.