I have been experimenting with the devstack setup on a Xen guest (if
possible I want to use Xen because I can take dumps there). The guest
setup is 2VCPUs, 1G memory and 8G and 5G virtual disks (the second is
mounted to /opt/stack to be used by the volume group of the test. This
is a remainder of the other setup and I surely can reinstall with a
single big enough disk. There is about 1G of swap-space used on the
first disk.
Running the test, the snapshot is successfully created:
#> dmsetup ls --tree
stack--volumes-_snapshot--68081c3b--d18b--48ca--8f15--e14ec8b0606e (252:1)
├─stack--volumes-_snapshot--68081c3b--d18b--48ca--8f15--e14ec8b0606e-cow (2...
│ └─ (7:0)
└─stack--volumes-volume--37759b39--408e--4f2a--a58c--9b0adf9dfa43-real (252...
└─ (7:0)
stack--volumes-volume--37759b39--408e--4f2a--a58c--9b0adf9dfa43 (252:0)
└─stack--volumes-volume--37759b39--408e--4f2a--a58c--9b0adf9dfa43-real (252...
└─ (7:0)
When deleting the snapshot, the system gets under pressure (and the
timeout of 30s seems too short for erasing 2G). In contrast to what the
lvm commands in comment #32 said, it is the snapshot volume that gets
erased:
6652 pts/14 S+ 0:00 sudo /usr/local/bin/cinder-rootwrap
/etc/cinder/rootwrap.conf dd if=/dev/zero of=/dev/mapper/stack--volumes-
_snapshot--68081c3b--d18b--48ca--8f15--e14ec8b0606e count=2048 bs=1M
This actually makes a lot of sense because erasing the origin volume
would cause much more IO in the background as every block that gets
erased is first copied into the exception storage. By erasing the
snapshot only the zeroed block gets written to the exception storage and
(not sure how often) the persistent COW table has to be updated.
While for me the system does not hang, I notice that after the activity
caused by the erase stops (and nova volume-snapshot-list now returns
nothing), the device-mapper setup is not clean:
#> dmsetup ls --tree
stack--volumes-_snapshot--68081c3b--d18b--48ca--8f15--e14ec8b0606e-cow (252:...
└─ (7:0)
stack--volumes-volume--37759b39--408e--4f2a--a58c--9b0adf9dfa43 (252:0)
└─ (7:0)
#> lvs
LV VG Attr LSize Origin
Snap% Move Log Copy% Convert
volume-37759b39-408e-4f2a-a58c-9b0adf9dfa43 stack-volumes -wi-ao 2.00g
So the snapshot was mostly disbanded but the exception storage is still
present. Though I was able to remove it manually via dmsetup. After
doing that, I could issue a "nova volume-delete" to get rid of the
origin volume, too (note, this again does a dd but compared to the dd on
the snapshot, this one seems much fater).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1023755
Title:
Precise kernel locks up while dd to /dev/mapper files > 1Gb (was:
Unable to delete volume)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1023755/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
