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

_______________________________________________
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