Comment 33 for bug 1023755

Just while thinking about it (not yet run a reproduction), I think I can guess around where the problem might be. Both the original volume and the snapshot are set to 2G (at least in the example). The way a snapshot volume works is that it contains a mapping table. Sectors that have not changed in either the original or the snapshot will refer to the original volume. Changes to the origin will cause a copy of the original sector into the exception storage and the table to be updated to point to the exception storage. Writes to the snapshot go into the exception storage directly and the table is updated as before. For this reason the snapshot volume is not a plain volume but is used to store the mapping table and the exception sectors. The table gets bigger with the original volume's size. So I guess around this 2G size a 2G snapshot cannot store exceptions to all sectors, which is what happens when zeroing the whole origin.
Theoretically I would think a write should return an error in that case. But maybe this is a problem caused by having the VG mapped onto a loop device. Also the whole system hanging is unexpected. Could the lack of propagating IO error possibly cause the dd not to see the end of the device, so in the end all memory is exhausted by buffers that cannot be written?

This potentially can be a problem too, if the user of the used device (I assume the origin is used to export and allow its user to update the contents while the snapshot retains the unmodified state) happens to modify _all_ sectors (though I think that will be quite rare. So much for theories. Need to find out whether that is actually true. Might be worth trying to make the snapshot a bit bigger and see what happens. Ultimately I guess one wants to convert the snapshot storage into a linear volume and then erase it (or have it erased while dropping).