All of lore.kernel.org
 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 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.