All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: patrik@dsl.sk
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: Reducing size of thin spare metadata, thin metadata
Date: Mon, 06 Oct 2014 10:05:43 +0200	[thread overview]
Message-ID: <54324D57.1050704@redhat.com> (raw)
In-Reply-To: <CAAOsTS=ufw7KgFMOW79+4_kwexnp=pALQWR7BLRSr_JUk6xGXQ@mail.gmail.com>

Dne 6.10.2014 v 09:59 Patrik Horník napsal(a):
> Hi,
>
> 2014-10-06 9:39 GMT+02:00 Zdenek Kabelac <zkabelac@redhat.com>:
>> Dne 6.10.2014 v 09:28 Patrik Horník napsal(a):
>>
>>> Hi,
>>>
>>> is it possible to (safely) reduce size of thin metadata and / or thin
>>> spare metadata? What size of spare metadata is needed? Can it be
>>> smaller than size of pool metadata?
>>>
>>
>> You could remove pool spare volume anytime  - lvremove.
>> (it's only used for automated lvconvert --repair)
>>
>> Repair needs free space in VG - if there is no free space - well tool can't
>> be used.
>
> when does automated lvconvert --repair kick in? Can I do it manually
> if it cannot continue automatically? (I actually have space for spare
> metadata so I want it there if it useful but smaller. I only need to
> decrease size of my volume group by couple of 100s MB because of
> moving to new device. My spare is 8 GB as is regular metadata.)

When thin-pool does not pass 'thin-check' during thin-pool activation,
you could try to use this  'lvconvert --repair' at first.

Basically it automates steps described in previous mail - except it will try 
to use bigger 'replaceable' LV.

Yet the functionality is not really any better then that - it's still missing
many validation checks between user-land lvm2 metadata and kernel-land 
thin-pool metadata.

But it's being improved.
Meanwhile any 'major' damage of thin-pool metadata do need  'hand' work repair 
- since human can do far better decision then this initial implementation.

Also note - any pool damage is still important to be reported - as
thin pool metadata should be nearly impossible to break in the first place ;)

Zdenek

  reply	other threads:[~2014-10-06  8:05 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 [this message]
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

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=54324D57.1050704@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=patrik@dsl.sk \
    /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.