Thanks for your response! > You need to show your 'broken' table first. $ dmsetup table backup: 0 11720531968 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 9:10 4096 > However for the 'standard' linear device - you could always replace > opened device with error target with '--force'. I'm not sure how to do this, could you please elaborate? I thought "dmsetup remove --force" would do this but as that doesn't work, I tried this also: $ dmsetup wipe_table backup <no response, dmsetup frozen, kill -9 doesn't work> $ dmsetup reload backup --table "0 11720531968 error" $ dmsetup info backup Name: backup State: ACTIVE Read Ahead: 4096 Tables present: LIVE & INACTIVE Open count: 1 Event number: 0 Major, minor: 253, 0 Number of targets: 1 UUID: CRYPT-LUKS1-d0b3d38e421545908537dc50f59fb217-backup $ dmsetup resume backup <no response, dmsetup frozen, kill -9 doesn't work> > What you can't expect is 'device deletion' - as long as device is > opened, it will be present (even if all read & writes will be > errored). That's probably ok, what I'm really trying to do is to get the underlying device released. > Also note - dmsetup remove supports --deferred removal (see man > page). Oh I didn't notice that. It doesn't seem to have much of an effect though: $ dmsetup remove --deferred backup $ dmsetup info Name: backup State: ACTIVE (DEFERRED REMOVE) Read Ahead: 4096 Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 0 Number of targets: 1 UUID: CRYPT-LUKS1-d0b3d38e421545908537dc50f59fb217-backup The underlying device is still in use by dm-crypt. I could not unmount the filesystem stored on the dm device as the kernel said it was still in use (presumably by the pending writes), so I did a lazy unmount of the filesystem. I think this is what's holding the dm device open and causing dmsetup to stop responding all the time. Any suggestions how to proceed? Thanks again, Adam. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
