All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marian Csontos <mcsontos@redhat.com>
To: patrik@dsl.sk, device-mapper development <dm-devel@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>
Subject: Re: Fwd: Reducing size of thin spare metadata, thin metadata
Date: Tue, 07 Oct 2014 09:17:45 +0200	[thread overview]
Message-ID: <54339399.7060707@redhat.com> (raw)
In-Reply-To: <CAAOsTSnJy21c4x8rO6ewVatsTLdTAZ=ERPg71Gf4s0V-qOD0cg@mail.gmail.com>

On 10/06/2014 11:05 AM, Patrik Horník wrote:
> Thank you very much, now I understand.
>
> But apparently I dont understand exact function of " lvconvert
> --thinpool  vg/mypool   --poolmetadata mytemplv" So it also copies
> metadata from current metadata LV to mytemplv?

Nope, the metadata are copied by `thin_repair` step:

# thin_repair  -i /dev/vg/mytemplv   -o /dev/vg/mynewsizemeta

The lvconvert "only" swaps LVs.

-- Martian

>
> Then what about "lvconvert --thinpool  vg/mypool   --poolmetadata
> mynewsizemeta"? It does not do that because mynewsizemeta is smaller
> than current metadata mytemplv or?
>
>
> 2014-10-06 10:57 GMT+02:00 Zdenek Kabelac <zkabelac@redhat.com>:
>> Dne 6.10.2014 v 10:48 Patrik Horník napsal(a):
>>>
>>> Thanks Zdenku. But you did not answer some of my questions, which I
>>> need to know to decide... So is there a way I can create smaller spare
>>> metadata LV? In mentioned manual steps what do I need mytemplv for and
>>> why cant I use original pool metadata as input of thin_repair?
>>
>>
>> Spare volume is maintained to have the size at least as the biggest
>> pool metadata volume in VG.
>>
>> There is no point to keep smaller reserved space.
>>
>> We do not allow to activate 'subvolumes' - thus you cannot activate
>> just 'thin pool metadata'  - that's why you need to swap _tmeta
>> out thin pool.
>>
>> Zdenek
>>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>

      reply	other threads:[~2014-10-07  7:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06  7:28 Reducing size of thin spare metadata, thin metadata Patrik Horník
2014-10-06  7:39 ` Zdenek Kabelac
2014-10-06  7:59   ` Patrik Horník
2014-10-06  8:05     ` Zdenek Kabelac
2014-10-06  8:12       ` Patrik Horník
2014-10-06  8:31         ` Zdenek Kabelac
2014-10-06  8:48           ` Patrik Horník
2014-10-06  8:57             ` Zdenek Kabelac
     [not found]               ` <CAAOsTS=j1mUA+caJ35ChDvpQJTu2m8OHVPCEZFTJHdn9cgdhsw@mail.gmail.com>
2014-10-06  9:05                 ` Fwd: " Patrik Horník
2014-10-07  7:17                   ` Marian Csontos [this message]

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=54339399.7060707@redhat.com \
    --to=mcsontos@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=patrik@dsl.sk \
    --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.