archive mirror
 help / color / mirror / Atom feed
From: Liwei <>
To: LVM general discussion and development <>
Subject: Re: [linux-lvm] Detaching a failed cache pool
Date: Thu, 8 Nov 2018 01:19:54 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 24 Oct 2018 at 14:36, Liwei <> wrote:
> Hi list,
>     I have an LV with a corrupted cache. Looking at the cmeta using
> cache_dump, I get this:
> <superblock uuid="" block_size="128" nr_cache_blocks="0" policy=""
> hint_width="4">
>   <mappings>
> metadata contains errors (run cache_check for details).
> perhaps you wanted to run with --repair ?
>     Running with --repair just produces metadata with no mappings and
> hints, which is incorrect too.
>     Obviously the metadata volume is corrupted beyond recovery, but I
> am okay with that as it is a read-only LV and we are using the cache
> for read acceleration. However, there seems to be no way for us to get
> out of this state into something usable? I can't seem to remove the
> cache from the LV. I've read through the documentation for lvmcache
> and can't find any information about this.
>     At the moment I can't access the original LV anymore. Whatever I
> try to do always results in "Check of pool vg/lv-cache failed
> (status:1). Manual repair required!" What am I missing?
> Thanks!
> Liwei

Okay, just a quick response to close up this issue. There is a simple solution.

Note that this only makes sense for a writethrough cache as whatever
is in the cache should be safe to discard. I'm not sure if it makes
sense to try this for other cache types. Please do make sure you
understand what's happening before trying the following.

Also, this is based on very limited understanding I have obtained from
trying to search for a solution. Those who are more experienced please
do correct me if what I'm doing is superfluous, stupid or just
outright dangerously wrong!

Assuming the block_size of 128 sectors is correct, I simply have to
calculate the correct nr_cache_blocks and edit the generated cmeta xml

Once edited, run cache_restore using the modified xml file to generate
the required metadata (albeit an empty cache). Swap the cmeta LV back
into the cache LV and it should stop complaining. At this point, I
could split off the cache pool from the origin LV and work with my
origin LV as per a normal uncached LV.

To be sure of the block_size and nr_cache_blocks, you can try creating
a dummy cache pool LV of the exact size and dump its cmeta as xml.
Assuming you're using the same kernel and lvm tools versions, the
block_size should match the corrupted one.

(Then again, I realise if we're going to thrash the cache anyway, we
don't need the block_size to be correct, just make sure that
block_size and nr_cache_blocks make sense in covering the entire cdata

Hope this helps!

      reply	other threads:[~2018-11-07 17:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24  6:36 [linux-lvm] Detaching a failed cache pool Liwei
2018-11-07 17:19 ` Liwei [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* 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).