Some thoughts on the previous data:
1. With devstack running it is likely that some portions of the 1G memory are used by executables.
2. Having the VG on a loop mounted file can add some overhead on the IO as everything has to
go trhough an additional layer and it is not guaranteed that consecutive blocks of the loop
block device map to sequential blocks in the file system. That could make merges harder.
3. I am not sure whether for the Virtualbox VM a paravirtual device driver exists or whether block
devices are presented through an emulated controller (often PIIX). Compared to the paravirt
driven block devices I use, the emulated devices are much slower.
4. Another factor that is often causing problems is that with 12.04, the default IO scheduler changed
from deadline to cfq. It might be worth a try to set "elevator=deadline" in the kernel command
line.
Looking at this, this could be a combination of slower block devices and memory pressure and possibly some other event that causes problems for the kernel tread that has to maintain a valid exception table on disk while writing the zero blocks. At least this causes non-sequential access patterns as the exception table is somewhere at the start of the snapshot COW. As those need to be synchronized, this would explain why erasing the snapshot takes much longer.
Next I would try to force the Xen guest to use emulated devices.
Some thoughts on the previous data:
1. With devstack running it is likely that some portions of the 1G memory are used by executables.
2. Having the VG on a loop mounted file can add some overhead on the IO as everything has to
go trhough an additional layer and it is not guaranteed that consecutive blocks of the loop
block device map to sequential blocks in the file system. That could make merges harder.
3. I am not sure whether for the Virtualbox VM a paravirtual device driver exists or whether block
devices are presented through an emulated controller (often PIIX). Compared to the paravirt
driven block devices I use, the emulated devices are much slower.
4. Another factor that is often causing problems is that with 12.04, the default IO scheduler changed
from deadline to cfq. It might be worth a try to set "elevator=deadline" in the kernel command
line.
Looking at this, this could be a combination of slower block devices and memory pressure and possibly some other event that causes problems for the kernel tread that has to maintain a valid exception table on disk while writing the zero blocks. At least this causes non-sequential access patterns as the exception table is somewhere at the start of the snapshot COW. As those need to be synchronized, this would explain why erasing the snapshot takes much longer.
Next I would try to force the Xen guest to use emulated devices.