linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Gionatan Danti <g.danti@assyoma.it>,
	LVM general discussion and development <linux-lvm@redhat.com>,
	listac@nebelschwaden.de
Subject: Re: [linux-lvm] metadata device too small
Date: Mon, 13 Jan 2020 15:49:27 +0100	[thread overview]
Message-ID: <ba1b5f76-88eb-67df-29bd-029813303200@redhat.com> (raw)
In-Reply-To: <fa490a40-1c58-f905-b5bb-93df3c9f22a2@assyoma.it>

Dne 13. 01. 20 v 15:32 Gionatan Danti napsal(a):
> On 12/01/20 19:11, Zdenek Kabelac wrote:
>> With 16G there is 'problem' (not yet resolved known issue) with different 
>> max size used by thin_repair (15.875G) & lvm2 (15.8125G) tools.
>>
>> If you want to go with current max size supported by lvm2 - use the value 
>> -L16192M.
> 
> Hi Zdenek,
> just for confirmation: so using a 16 GiB thin metadata volume *will* result in 
> activation problems? For example, a
> 
> lvcreate --thin system --name thinpool -L 100G --poolmetadatasize 16G
> 
> will be affected by the problem you wrote above?
> 
> Finally, does it means that lvmthin man page is wrong when stating that "Thin 
> pool metadata LV sizes can be from 2MiB to 16GiB" (note the GiB suffix rather 
> than GB)?
> 

Hi

Well the size is 'almost' 16GiB - and when the size of thin-pools metadata is 
always maintained by lvm2 - it's OK -  the size is internally 'clamped' 
correctly - the problem is when you use this size 'externally' - so you make 
16GiB regular LV used for thin-repair - and then you swap-in such LV into 
thin-pool.

So to make it clear - when you 'lvcreate' thin-pool with 16GiB of metadata - 
it will work - but then when you will try to fix such thin-pool - it will 
fail.  So it's always better to create thin-pool with  -L15.812G then using  16G.

Regards

Zdenek

  reply	other threads:[~2020-01-13 14:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11 17:57 [linux-lvm] metadata device too small Ede Wolf
2020-01-11 22:00 ` Ede Wolf
2020-01-11 22:07   ` Ede Wolf
2020-01-13 15:02     ` Marian Csontos
2020-01-13 16:35       ` Ede Wolf
2020-01-13 19:11         ` Zdenek Kabelac
     [not found]           ` <74436e16-d2f6-71a0-c264-71ce417de08c@nebelschwaden.de>
2020-01-13 21:29             ` Ede Wolf
2020-01-12 18:11 ` Zdenek Kabelac
2020-01-13 14:32   ` Gionatan Danti
2020-01-13 14:49     ` Zdenek Kabelac [this message]
2020-01-13 15:25       ` Gionatan Danti

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=ba1b5f76-88eb-67df-29bd-029813303200@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.danti@assyoma.it \
    --cc=linux-lvm@redhat.com \
    --cc=listac@nebelschwaden.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).