Bug 509763 - dmsetup --suspend-and-resume should be provided
dmsetup --suspend-and-resume should be provided
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-05 18:39 EDT by Maciej Żenczykowski
Modified: 2009-07-06 01:31 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-05 18:57:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Maciej Żenczykowski 2009-07-05 18:39:01 EDT
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]
Comment 1 Alasdair Kergon 2009-07-05 18:52:11 EDT
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.
Comment 2 Alasdair Kergon 2009-07-05 18:57:17 EDT
(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.)
Comment 3 Maciej Żenczykowski 2009-07-06 01:31:07 EDT
$ 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)

Note You need to log in before you can comment on or make changes to this bug.