[dm-devel] [PATCH v2 2/2] dm: allow active and inactive tables to share dm_devs

[Mike Snitzer]

I've revised the header for this patch:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=d379c2886c48b32d5f4cf70a27ba2409e127b6f7

dm: allow active and inactive tables to share dm_devs

Until this change, when loading a new DM table, DM core would re-open
all of the devices in the DM table. Now, DM core will avoid redundant
device opens (and closes when destroying the old table) if the old table
already has a device open using the same mode. This is achieved by
managing reference counts on the table_devices that DM core now stores
in the mapped_device structure (rather than in the dm_table
structure). So a mapped_device's active and inactive dm_tables' dm_dev
lists now just point to the dm_devs stored in the mapped_device's
table_devices list.

This improvement in DM core's device reference counting has the
side-effect of fixing a long-standing limitation of the multipath
target: a DM multipath table couldn't include any paths that were
unusable (failed). For example: if all paths have failed and you add a
new, working, path to the table; you can't use it since the table load
would fail due to it still containing failed paths. Now a re-load of a
multipath table can include failed devices and when those devices become
active again they can be used instantly.


The device list code in dm.c isn't a straight copy/paste from the code
in dm-table.c, but it's very close (aside from some variable
renames). One subtle difference is that find_table_device for the
tables_devices list will only match devices with the same name and
mode. This is because we don't want to upgrade a device's mode in the
active table when an inactive table is loaded. Access to the
mapped_device structure's tables_devices list requires a mutex
(tables_devices_lock), so that tables cannot be created and destroyed
concurrently.

Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>
Signed-off-by: Mike Snitzer <snitzer at redhat.com>