"vgchange -a n VG" freezes, other LVM commands too

I just wanted to deactivate a volume group - I used:

vgchange -a n volume_group

Unfortunately, it didn't work and it seems frozen - the command is still being executed, and is in "D" state.

Any other LVM command (lvs etc.) freezes as well (D state), adding +1 to the system load average.

This is what happens when I start lvs with verbose/debug parameters:

# lvs -vvvv -dddd
#lvmcmdline.c:871         Processing: lvs -vvvv -dddd
#lvmcmdline.c:874         O_DIRECT will be used
#config/config.c:846       Setting global/locking_type to 1
#config/config.c:823       Setting global/locking_dir to /var/lock/lvm
#locking/locking.c:139       File-based locking enabled.
#config/config.c:851       report/aligned not found in config: defaulting to 1
#config/config.c:851       report/buffered not found in config: defaulting to 1
#config/config.c:851       report/headings not found in config: defaulting to 1
#config/config.c:829       report/separator not found in config: defaulting to
#config/config.c:829       report/lvs_sort not found in config: defaulting to vg_name,lv_name
#config/config.c:829       report/lvs_cols_verbose not found in config: defaulting to lv_name,vg_name,seg_count,lv_attr,lv_size,lv_major,lv_minor,lv_kernel_major,lv_kernel_minor,origin,snap_percent,move_pv,copy_percent,mirror_log,lv_uuid
#toollib.c:286     Finding all logical volumes
#device/dev-io.c:439         Opened /dev/loop0 RO
#device/dev-io.c:264       /dev/loop0: size is 0 sectors
#filters/filter.c:106         /dev/loop0: Skipping: Too small to hold a PV
#device/dev-io.c:485         Closed /dev/loop0
#device/dev-io.c:439         Opened /dev/sda RO
#device/dev-io.c:264       /dev/sda: size is 3985632 sectors
#device/dev-io.c:134         /dev/sda: block size is 4096 bytes
#filters/filter.c:112         /dev/sda: Skipping: Partition table signature found
#device/dev-io.c:485         Closed /dev/sda
#device/dev-io.c:439         Opened /dev/sdq RO O_DIRECT
#device/dev-io.c:134         /dev/sdq: block size is 4096 bytes

And it stays there.

Any clues how to unblock it?

If it is important, some other kernel thread (drbd0_worker from DRBD) is/was accessing that volume group when I started that command.

Tomasz Chmielewski
http://wpkg.org

Oh, it looks like it's a dead iSCSI session that got in the way... With a timeout set to 10 days or so. Well, let's wait 10 days and see what happens.

Tomasz Chmielewski
http://wpkg.org