All of lore.kernel.org
 help / color / mirror / Atom feed
From: "M.H. Tsai" <mingnus@gmail.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: Thu, 31 Dec 2015 17:06:30 +0800	[thread overview]
Message-ID: <CAAYit8TZV55HM5LwBzWH6wqppYjFfJaVY4hxXS0eFFfJNi9ESQ@mail.gmail.com> (raw)
In-Reply-To: <5682F5F2.1000804@redhat.com>

2015-12-30 5:06 GMT+08:00 Zdenek Kabelac <zkabelac@redhat.com>:
>> I have three questions:
>>
>> 1. If we need to preserve the -tpool layer, why the commit 00a45ca4
>> activates a new thinpool (transaction_id == 0) without overlay?
>
> This comes from request to support  'external' thin-pool users - so
> lvm2 only manages thin-pool resize - but does not create thin LVs -
> it's docker's business...
>
> But the rule is - users' usable LV do have public names and UUID.
> Hidden/private  LVs have suffices in UUID.
> (In the future all hidden LVs should have UUID suffix for easy
> identification
> by blkid)

I found the discussion thread and related commits (in 2014-11-04).
I'll read it later.
https://github.com/docker/docker/issues/15629

>> 2. Is it necessary to suspend any thin volume while extending a
>> thinpool? If not, the commit fa648234 might need some fix.
>
> Well technically it would likely be better to do a suspend from
> all top-level LVs - but ATM thin-pool does use 'internal'
> suspend - there are couple associated issue - like usage of
> flush during such suspend (see comment bellow)
>
>
>> 3. Similary to question(2), is it necessary to suspend thin-pool while
>> expanding a thin-volume ? If no, we should adopt the approach of
>> a900d150e for thin-volume expansion. The following is my solution:
>
> Nope, even the current solution is rather 'short-time' hack
> until better fitting way is found (the hack needs some libdm API
> interface rather then some autonomous decision)
> But since current thin-pool target is missing couple features,
> we need to first improve kernel target.
>
> In general we need 'suspend with flush' which will not block, when pool
> runs out of space as suspend without flush is in general not so much
> useful.
>
> Unsure how much you interested in development of lvm2 code?
> Are you targeting some specific feature?

I'm the maintainer of LVM for my company's NAS. We just take daily
snapshot for backup.

For question(2), the kernel's pool_presuspend() function suspends all
the active thin volumes. Does that mean we don't need to suspend all
the thin volumes explicitly? Also, the current LVM only suspends the
"first" thin volume, which looks confusing.

The main concern for question (3) is IO performance -- taking
snapshots or expanding a thin volume should not affect IO of other
volumes or the entire pool.

  reply	other threads:[~2015-12-31 13:07 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
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 [this message]
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=CAAYit8TZV55HM5LwBzWH6wqppYjFfJaVY4hxXS0eFFfJNi9ESQ@mail.gmail.com \
    --to=mingnus@gmail.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.