Currently the only way I can find to load a new table into a device mapper device is to load it in as an inactive table, then suspend the device, then resume the device. Ie. dmsetup load X [-r] --table "`dmsetup table --showkeys X`" dmsetup suspend X dmsetup resume X should load in the same as the current table (possibly changing whether the table is read-only or read-write) and otherwise be a no-op. While this does indeed appear to work, this might not work all that well if the dmsetup binary is actually on X. Sure - most of the time it'll be in the cache, but I've had this fail now for the root device. Possibly a 'dmsetup suspend-and-resume' command could maybe fix this? This functionality is useful for: a) putting in an actual new table b) changing the r/w vs. r/o status, while keeping the same table c) forcing the device-mapper kernel drivers to re-fetch some internal state from the destination drives -- this is useful if the destination drive is an md raid array, and the set of devices in it have changed, thus changing (for example) the maximum block size supported by the array [sata drives do 248 blocks, usb-storage does 240 blocks, insert a usb drive into a raid array with only sata drives and the resulting max block size supported by the array drops from 248 to 240, without the device-mapper driver being aware - only way to fix is to force a table reload]
dmsetup is a low-level utility that acts as an intelligent wrapper around the device-mapper ioctls primarily for debugging/recovery purposes. It already offers the option of combining load+resume with create, but there are no plans to find a way to offer that combination independently. It's really the job of whatever tool you're using to load the mappings in the first place (cryptsetup?) to offer you the functionality you're requesting. In the case of LVM2, for example, there is lvchange --refresh which reloads the existing table.
(dmsetup is simply not designed to be used in cases where the binary is on the device being changed - it's only for debugging/recovery as I said. On the other hand, the underlying library, libdevmapper, is designed for such operation, and both the lvm and multipath binaries have modes that take advantage of that.)
$ man cryptsetup DEPRECATED ACTIONS reload <name> <device> modifies an active mapping <name>. Same options as for create. WARNING: Do not use this for LUKS devices, as the semantics are identical to the create action, which are totally incompatible with the LUKS key setup. This action is deprected because it proved to be rarely useful. It is uncommon to change the underlying device, key, or offset on the fly. In case, you really want to do this, you certainly know what you are doing and then you are probably better off with the swiss knive tool for device mapper, namely dmsetup. It provides you with the same functionality, see dmsetup reload. (it really seems to me like duplicating functionality all over the place is pointless)