All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Gionatan Danti <g.danti@assyoma.it>
Subject: Re: [linux-lvm] lvmcache with vdo - inconsistent block size
Date: Thu, 17 Sep 2020 21:27:20 +0200	[thread overview]
Message-ID: <4f98430e-f6eb-b7b7-d1b0-f54ad07361de@redhat.com> (raw)
In-Reply-To: <056d2d5dd9a7846a56971ce5f4cb3537@assyoma.it>

Dne 16. 09. 20 v 0:32 Gionatan Danti napsal(a):
> 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).
> 

You've most likely found the bug and this should be likely disable
(and enabled only with some force option).

Problem is, when such device stack is used for XFS - where the 'geometry' 
changes, but for some other it's not a big issue (i.e. ext4).

So if you already hit some problem - feel free to open upstream BZ for this issue.

Zdenek

  reply	other threads:[~2020-09-17 19:27 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
2020-09-17 19:27     ` Zdenek Kabelac [this message]
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=4f98430e-f6eb-b7b7-d1b0-f54ad07361de@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.danti@assyoma.it \
    --cc=linux-lvm@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.