All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Possible bug in expanding thinpool: lvextend doens't expand the top-level dm-linear device
Date: Fri, 25 Dec 2015 19:37:29 +0100	[thread overview]
Message-ID: <567D8CE9.3030101@redhat.com> (raw)
In-Reply-To: <CAAYit8RpRFgYyeHmxyhOco=gxnYgoGPJBa_ssY+xq-D3S70GPw@mail.gmail.com>

Dne 25.12.2015 v 03:27 M.H. Tsai napsal(a):
> Hi,
>
> Sorry, what's the purpose of commit cd8e95d9337207a8f87a6f68dc9b1db7e3828bbf ?
>

Ahh my mistake - related to rename...

> Another issue is, the current code suspends the first thin volume
> (just the first one!)
> while extending a thinpool, which is unnecessary and also harms IO performance.
>
> Also, If the top-level "fake" pool device is unimportant, why not
> remove it, or simply
> make tp1 as a thin-pool target? It seems that the commit 00a45ca4 want
> to do this,
> it removes the -tpool layer while activating a new thinpool. But if
> there are thin
> volumes, the -tpool layer back again. This make me confused -- Do we really need
> layers?
>

It's not so simple - since the user may activate  thin-pool without activation 
of any thin-volume, and keep thin-pool active while thin-volumes are activated 
and deactivated - so it's different case if user activates
thin-pool explicitly or thin-pool is activated as thin volume dependency.

Also thin-pool LV has its own cluster lock which is quite complicated to 
explain, but for now -  thin-pool size is unimportant, but it's existence is 
mandatory :)

There is no simple way to avoid using current  'layer' logic, but as said
I've already do have some plan how to go without 'extra' layer 'fake' LV,
but it will take some time to implement.

Regards

Zdenek

  reply	other threads:[~2015-12-25 18:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23  9:50 [linux-lvm] Possible bug in expanding thinpool: lvextend doens't expand the top-level dm-linear device M.H. Tsai
2015-12-24  9:04 ` Zdenek Kabelac
2015-12-25  2:27   ` M.H. Tsai
2015-12-25 18:37     ` Zdenek Kabelac [this message]
2015-12-27  9:19       ` M.H. Tsai
2015-12-27 13:09       ` M.H. Tsai
2015-12-29 21:06         ` Zdenek Kabelac
2015-12-31  9:06           ` M.H. Tsai
2015-12-31 21:25             ` Zdenek Kabelac
2016-01-01 18:10               ` M.H. Tsai
2016-01-02 23:05                 ` Zdenek Kabelac
2016-01-04  5:08                   ` M.H. Tsai
2016-01-04 13:27                     ` Zdenek Kabelac
2016-02-12 12:40         ` Zdenek Kabelac

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=567D8CE9.3030101@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@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.