Bug 159877

reproduced again with exact same above senario.

This is caused by a force remove of an active lv.

[root@link-02 ~]# lvscan
  ACTIVE            '/dev/stripe_8_4096_4/stripe_8_4096_40' [924.00 GB] anywhere


lvremove -f /dev/stripe_8_4096_4/stripe_8_4096_40

strace:

[...]
stat("/dev/sdf1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 81), ...}) = 0
stat("/dev/sdf1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 81), ...}) = 0
open("/dev/sdf1", O_RDWR|O_DIRECT|0x40000) = 5
fstat(5, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 81), ...}) = 0
ioctl(5, BLKBSZGET, 0x67f9a0)           = 0
lseek(5, 2048, SEEK_SET)                = 2048
read(5, "_\332\24\f LVM2 x[5A%r0N*>\1\0\0\0\0\10\0\0\0\0\0\0"..., 512) = 512
lseek(5, 4096, SEEK_SET)                = 4096
read(5, "stripe_8_4096_4 {\nid = \"ADcb5J-K"..., 512) = 512
close(5)                                = 0
lseek(4, 0, SEEK_SET)                   = 0
read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2048) = 2048
lseek(4, 2048, SEEK_SET)                = 2048
read(4, "_\332\24\f LVM2 x[5A%r0N*>\1\0\0\0\0\10\0\0\0\0\0\0"..., 512) = 512
lseek(4, 4096, SEEK_SET)                = 4096
read(4, "stripe_8_4096_4 {\nid = \"ADcb5J-K"..., 512) = 512
close(4)                                = 0
brk(0x6db000)                           = 0x6db000
open("/proc/devices", O_RDONLY)         = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a97c3b000
read(4, "Character devices:\n  1 mem\n  4 /"..., 1024) = 445
close(4)                                = 0
munmap(0x2a97c3b000, 4096)              = 0
open("/proc/misc", O_RDONLY)            = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a97c3b000
read(4, " 60 dlm_clvmd\n 61 gnbd_ctl\n 62 d"..., 1024) = 94
close(4)                                = 0
munmap(0x2a97c3b000, 4096)   
stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 63),
...}) = 0
open("/dev/mapper/control", O_RDWR)     = 4
ioctl(4, DM_VERSION, 0x6ba260)          = 0
ioctl(4, DM_DEV_STATUS, 0x6a41c0)       = 0
brk(0x6d3000)                           = 0x6d3000
uname({sys="Linux", node="link-01", ...}) = 0
open("/etc/lvm/archive/.lvm_link-01_9269_145392622",
O_WRONLY|O_APPEND|O_CREAT|O_EXCL, 0666) =5
fcntl(5, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
fcntl(5, F_GETFL)                       = 0x8401 (flags
O_WRONLY|O_APPEND|O_LARGEFILE|0x8000)
fstat(5, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2a97c3b000
lseek(5, 0, SEEK_CUR)                   = 0
uname({sys="Linux", node="link-01", ...}) = 0
write(5, "# Generated by LVM2: Wed Jun  8 "..., 2292) = 2292
close(5)                                = 0
munmap(0x2a97c3b000, 4096)              = 0
open("/etc/lvm/archive", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 5
fstat(5, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
getdents64(5, /* 88 entries */, 4096)   = 3472
getdents64(5, /* 0 entries */, 4096)    = 0
close(5)                                = 0
link("/etc/lvm/archive/.lvm_link-01_9269_145392622",
"/etc/lvm/archive/stripe_8_4096_4_00008.vg") = 0
stat("/etc/lvm/archive/.lvm_link-01_9269_145392622", {st_mode=S_IFREG|0600,
st_size=2292, ...}) = 0
unlink("/etc/lvm/archive/.lvm_link-01_9269_145392622") = 0
write(3, "2\0\377\277\0\0\0\0\0\0\0\0C\0\0\0\0\30\0ADcb5JKgkAFga"..., 85) = 85
read(3,

Don't we get useful tracebacks on X86_64? oh dear. 
If it is caused by removing a volume then it could be a device-mapper bug.
Does it happen on a non-clustered system?

*** This bug has been marked as a duplicate of 158956 ***