All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: Teng-Feng Yang <shinrairis@gmail.com>
Subject: Re: Strange mapped block count kept by dm-thin driver for thin devices
Date: Wed, 28 Aug 2013 13:52:13 +0200	[thread overview]
Message-ID: <521DE46D.80609@redhat.com> (raw)
In-Reply-To: <CAKTMprNbFvezaSpAx7c2w2+qBzHp8dmJQLSeKEXfYtjSK5vGiw@mail.gmail.com>

Dne 28.8.2013 05:52, Teng-Feng Yang napsal(a):
> Hi,
>
> I have already noticed that the mapped block count of thin devices
> shown by "dmsetup status" looked unreasonable to me for a couple of
> times in the last six months.
> Sometimes the mapped block count was zero, but sometimes it was a
> large number which was obviously larger than the total available
> blocks in thin-pool.
> So I dig into the source code, and I find some codes look suspicious to me.
>
> In dm_pool_metadata_close() in dm-thin-metadata.c, it will try to
> commit transaction for the last time before it destroys the
> pmd(dm_pool_metadata).
> However, it does not lock the pool_metadata before transaction commit,
> which I am not really sure if we still need to acquire lock when it
> reaches here.
> I know that this function is mainly called when users try to remove
> pool, but it seems like we can still have some on-the-fly transaction
> commit when dm-thin module calls this function.
> Although I would like to test it by myself, this problem occurs in
> random and I am still trying to find a way to reproduce it
> systematically.
>
> Any help would be grateful.
>

I think it's good idea in this case to catch as much info in the moment you 
think you see a problem.

Take  output from:

dmsetup status/info/table
safe content of your metadata device for further analysis with thin 
provisioning tools.

Are you using lvm2 for thin volumes ?

Zdenek

      reply	other threads:[~2013-08-28 11:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  3:52 Strange mapped block count kept by dm-thin driver for thin devices Teng-Feng Yang
2013-08-28 11:52 ` Zdenek Kabelac [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=521DE46D.80609@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=shinrairis@gmail.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.