Dne 31.12.2015 v 10:06 M.H. Tsai napsal(a):
2015-12-30 5:06 GMT+08:00 Zdenek Kabelac <zkabelac@redhat.com>:
I have three questions:
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.
You should be aware of thin-pool limits.
i.e. ATM it's bad plan to use more then say 16 LVs in parallel for
a single thin-pool LV - it cannot be used in some massive parallel system
for its current locking mechanism.
There is even sequencing problem with creating snapshot in kernel target
which needs to be probably fixed first.
(the rule here should be - to never create/allocate something when
there is suspended device - and this rule is broken with current thin
snapshot creation - so thin snap create message should go in front
to ensure there is a space in thin-pool ahead of origin suspend - will
be addressed in some future version....)
However when taking snapshot - only origin thin LV is now suspended and
should not influence rest of thin volumes (except for thin-pool commit points)
minor warning - snapshot is not a backup - although it might look like it is :).
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/
