http://bugzilla.suse.com/show_bug.cgi?id=1114113
http://bugzilla.suse.com/show_bug.cgi?id=1114113#c1
--- Comment #1 from Gang He ---
The reproducible LV corruption I was seeing was from the following:
setup and start sanlock and lvmlockd
vgcreate --shared --metadatasize 1m foo /dev/sdg
(Note that this creates an internal "lvmlock" LV that sanlock uses to store
leases.)
lvcreate 500 inactive LVs in foo
vgremove foo
During the vgremove step, sanlock notices that its updates to the internal
"lvmlock" LV are periodically lost. It's because when vgremove writes metadata
at the end of the metadata area, it also clobbers PEs that were allocated to
the lvmlock LV. (sanlock reads/writes blocks to the lvmlock LV and notices if
data changes out from under it.)
It should be straight forward to reproduce this same issue without lvmlockd and
sanlock. Create an ordinary VG, create an initial small LV (that uses the
first PEs in the VG), start a script or program that reads/writes data to that
LV and verifies that what it wrote comes back again. Then start creating 500
other LVs in the VG, and removing those 500 LVs. This causes the LV metadata
to grow large and wrap around the end of the metadata area. When lvm writes to
the end of the metadata area, it will clobber data that the test program wrote
and the test program should eventually notice that its last write is missing.
--
You are receiving this mail because:
You are on the CC list for the bug.