use copy-on-write for all rbd volume cloning
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
Edward Hope-Morley |
Bug Description
RBD volume cloning (from vol not snap) currently does a full copy. We could speed this up by creating a copy-on-write clone instead. This would require taking a snapshot of the volume first and then creating a copy-on-write clone. There are different ways we could implement this, especially in view of upcoming auto-flattening support, but for now I suggest we do it as follows:
* create discrete snapshot of volume if one does not already exist
* if snapshot has > some-configurab
* create copy-on-write clone of snapshot
* et voila!
description: | updated |
Changed in cinder: | |
assignee: | nobody → Edward Hope-Morley (hopem) |
summary: |
- use copy-on-write for rbd volume cloning + use copy-on-write for all rbd volume cloning |
description: | updated |
Changed in cinder: | |
milestone: | none → havana-rc1 |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | havana-rc1 → 2013.2 |
Copying in message from Chen, Xiaoxi:
"I have discussed with josh about the auto-flatten feature, almost share the same idea with you from code basis but go to different direction.
My proposal for auto-flatten is when there are too many children, then when user want to delete the parent volume, we don’t actuall flatten all children ,instead, we just lazy-delete the parent volume instead --- to prevent a flatten storm.
Your proposal is if a snapshot has too many children ,then disabled the CoW mechanism,this is another approach for prevent a flatten storm, but it’s doubtful for performance reason, for example ,if you have a snapshot of OS-DISK, and a lot of volumes cloned from that snapshot, it’s likely the base-image(to be exactly, the snapshot) will be very hot and thus be cached in DRAM. So it may be even faster than you do a full copy."