Re: Possible bug in expanding thinpool: lvextend doens't expand the top-level dm-linear device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 27.12.2015 v 14:09 M.H. Tsai napsal(a):
Sorry, I sent a wrong mail before. Please ignore it.

2015-12-26 2:37 GMT+08:00 Zdenek Kabelac <zkabelac@redhat.com>:
Dne 25.12.2015 v 03:27 M.H. Tsai napsal(a):

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 :)

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)


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?

Zdenek


_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/



[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux