Commit c3cb5e19 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm 

* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm: (48 commits)
  dm mpath: change to be request based
  dm: disable interrupt when taking map_lock
  dm: do not set QUEUE_ORDERED_DRAIN if request based
  dm: enable request based option
  dm: prepare for request based option
  dm raid1: add userspace log
  dm: calculate queue limits during resume not load
  dm log: fix create_log_context to use logical_block_size of log device
  dm target:s introduce iterate devices fn
  dm table: establish queue limits by copying table limits
  dm table: replace struct io_restrictions with struct queue_limits
  dm table: validate device logical_block_size
  dm table: ensure targets are aligned to logical_block_size
  dm ioctl: support cookies for udev
  dm: sysfs add suspended attribute
  dm table: improve warning message when devices not freed before destruction
  dm mpath: add service time load balancer
  dm mpath: add queue length load balancer
  dm mpath: add start_io and nr_bytes to path selectors
  dm snapshot: use barrier when writing exception store
  ...
parents ea94b503 f40c67f0

Documentation/device-mapper/dm-log.txt

0 → 100644
+54 −0
Original line number Diff line number Diff line 
Device-Mapper Logging

=====================

The device-mapper logging code is used by some of the device-mapper

RAID targets to track regions of the disk that are not consistent.

A region (or portion of the address space) of the disk may be

inconsistent because a RAID stripe is currently being operated on or

a machine died while the region was being altered.  In the case of

mirrors, a region would be considered dirty/inconsistent while you

are writing to it because the writes need to be replicated for all

the legs of the mirror and may not reach the legs at the same time.

Once all writes are complete, the region is considered clean again.



There is a generic logging interface that the device-mapper RAID

implementations use to perform logging operations (see

dm_dirty_log_type in include/linux/dm-dirty-log.h).  Various different

logging implementations are available and provide different

capabilities.  The list includes:



Type		Files

====		=====

disk		drivers/md/dm-log.c

core		drivers/md/dm-log.c

userspace	drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h



The "disk" log type

-------------------

This log implementation commits the log state to disk.  This way, the

logging state survives reboots/crashes.



The "core" log type

-------------------

This log implementation keeps the log state in memory.  The log state

will not survive a reboot or crash, but there may be a small boost in

performance.  This method can also be used if no storage device is

available for storing log state.



The "userspace" log type

------------------------

This log type simply provides a way to export the log API to userspace,

so log implementations can be done there.  This is done by forwarding most

logging requests to userspace, where a daemon receives and processes the

request.



The structure used for communication between kernel and userspace are

located in include/linux/dm-log-userspace.h.  Due to the frequency,

diversity, and 2-way communication nature of the exchanges between

kernel and userspace, 'connector' is used as the interface for

communication.



There are currently two userspace log implementations that leverage this

framework - "clustered_disk" and "clustered_core".  These implementations

provide a cluster-coherent log for shared-storage.  Device-mapper mirroring

can be used in a shared-storage environment when the cluster log implementations

are employed.

Documentation/device-mapper/dm-queue-length.txt

0 → 100644
+39 −0
Original line number Diff line number Diff line 
dm-queue-length

===============



dm-queue-length is a path selector module for device-mapper targets,

which selects a path with the least number of in-flight I/Os.

The path selector name is 'queue-length'.



Table parameters for each path: [<repeat_count>]

	<repeat_count>: The number of I/Os to dispatch using the selected

			path before switching to the next path.

			If not given, internal default is used. To check

			the default value, see the activated table.



Status for each path: <status> <fail-count> <in-flight>

	<status>: 'A' if the path is active, 'F' if the path is failed.

	<fail-count>: The number of path failures.

	<in-flight>: The number of in-flight I/Os on the path.





Algorithm

=========



dm-queue-length increments/decrements 'in-flight' when an I/O is

dispatched/completed respectively.

dm-queue-length selects a path with the minimum 'in-flight'.





Examples

========

In case that 2 paths (sda and sdb) are used with repeat_count == 128.



# echo "0 10 multipath 0 0 1 1 queue-length 0 2 1 8:0 128 8:16 128" \

  dmsetup create test

#

# dmsetup table

test: 0 10 multipath 0 0 1 1 queue-length 0 2 1 8:0 128 8:16 128

#

# dmsetup status

test: 0 10 multipath 2 0 0 0 1 1 E 0 2 1 8:0 A 0 0 8:16 A 0 0

Documentation/device-mapper/dm-service-time.txt

0 → 100644
+91 −0
Original line number Diff line number Diff line 
dm-service-time

===============



dm-service-time is a path selector module for device-mapper targets,

which selects a path with the shortest estimated service time for

the incoming I/O.



The service time for each path is estimated by dividing the total size

of in-flight I/Os on a path with the performance value of the path.

The performance value is a relative throughput value among all paths

in a path-group, and it can be specified as a table argument.



The path selector name is 'service-time'.



Table parameters for each path: [<repeat_count> [<relative_throughput>]]

	<repeat_count>: The number of I/Os to dispatch using the selected

			path before switching to the next path.

			If not given, internal default is used.  To check

			the default value, see the activated table.

	<relative_throughput>: The relative throughput value of the path

			among all paths in the path-group.

			The valid range is 0-100.

			If not given, minimum value '1' is used.

			If '0' is given, the path isn't selected while

			other paths having a positive value are available.



Status for each path: <status> <fail-count> <in-flight-size> \

		      <relative_throughput>

	<status>: 'A' if the path is active, 'F' if the path is failed.

	<fail-count>: The number of path failures.

	<in-flight-size>: The size of in-flight I/Os on the path.

	<relative_throughput>: The relative throughput value of the path

			among all paths in the path-group.





Algorithm

=========



dm-service-time adds the I/O size to 'in-flight-size' when the I/O is

dispatched and substracts when completed.

Basically, dm-service-time selects a path having minimum service time

which is calculated by:



	('in-flight-size' + 'size-of-incoming-io') / 'relative_throughput'



However, some optimizations below are used to reduce the calculation

as much as possible.



	1. If the paths have the same 'relative_throughput', skip

	   the division and just compare the 'in-flight-size'.



	2. If the paths have the same 'in-flight-size', skip the division

	   and just compare the 'relative_throughput'.



	3. If some paths have non-zero 'relative_throughput' and others

	   have zero 'relative_throughput', ignore those paths with zero

	   'relative_throughput'.



If such optimizations can't be applied, calculate service time, and

compare service time.

If calculated service time is equal, the path having maximum

'relative_throughput' may be better.  So compare 'relative_throughput'

then.





Examples

========

In case that 2 paths (sda and sdb) are used with repeat_count == 128

and sda has an average throughput 1GB/s and sdb has 4GB/s,

'relative_throughput' value may be '1' for sda and '4' for sdb.



# echo "0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 1 8:16 128 4" \

  dmsetup create test

#

# dmsetup table

test: 0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 1 8:16 128 4

#

# dmsetup status

test: 0 10 multipath 2 0 0 0 1 1 E 0 2 2 8:0 A 0 0 1 8:16 A 0 0 4





Or '2' for sda and '8' for sdb would be also true.



# echo "0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 2 8:16 128 8" \

  dmsetup create test

#

# dmsetup table

test: 0 10 multipath 0 0 1 1 service-time 0 2 2 8:0 128 2 8:16 128 8

#

# dmsetup status

test: 0 10 multipath 2 0 0 0 1 1 E 0 2 2 8:0 A 0 0 2 8:16 A 0 0 8

drivers/md/Kconfig

+30 −0
Original line number Diff line number Diff line
@@ -231,6 +231,17 @@ config DM_MIRROR 
         Allow volume managers to mirror logical volumes, also

         needed for live data migration tools such as 'pvmove'.



config DM_LOG_USERSPACE

	tristate "Mirror userspace logging (EXPERIMENTAL)"

	depends on DM_MIRROR && EXPERIMENTAL && NET

	select CONNECTOR

	---help---

	  The userspace logging module provides a mechanism for

	  relaying the dm-dirty-log API to userspace.  Log designs

	  which are more suited to userspace implementation (e.g.

	  shared storage logs) or experimental logs can be implemented

	  by leveraging this framework.



config DM_ZERO

	tristate "Zero target"

	depends on BLK_DEV_DM
@@ -249,6 +260,25 @@ config DM_MULTIPATH 
	---help---

	  Allow volume managers to support multipath hardware.



config DM_MULTIPATH_QL

	tristate "I/O Path Selector based on the number of in-flight I/Os"

	depends on DM_MULTIPATH

	---help---

	  This path selector is a dynamic load balancer which selects

	  the path with the least number of in-flight I/Os.



	  If unsure, say N.



config DM_MULTIPATH_ST

	tristate "I/O Path Selector based on the service time"

	depends on DM_MULTIPATH

	---help---

	  This path selector is a dynamic load balancer which selects

	  the path expected to complete the incoming I/O in the shortest

	  time.



	  If unsure, say N.



config DM_DELAY

	tristate "I/O delaying target (EXPERIMENTAL)"

	depends on BLK_DEV_DM && EXPERIMENTAL

drivers/md/Makefile

+5 −0
Original line number Diff line number Diff line
@@ -8,6 +8,8 @@ dm-multipath-y += dm-path-selector.o dm-mpath.o 
dm-snapshot-y	+= dm-snap.o dm-exception-store.o dm-snap-transient.o \

		    dm-snap-persistent.o

dm-mirror-y	+= dm-raid1.o

dm-log-userspace-y \

		+= dm-log-userspace-base.o dm-log-userspace-transfer.o

md-mod-y	+= md.o bitmap.o

raid456-y	+= raid5.o

raid6_pq-y	+= raid6algos.o raid6recov.o raid6tables.o \
@@ -36,8 +38,11 @@ obj-$(CONFIG_BLK_DEV_DM) += dm-mod.o 
obj-$(CONFIG_DM_CRYPT)		+= dm-crypt.o

obj-$(CONFIG_DM_DELAY)		+= dm-delay.o

obj-$(CONFIG_DM_MULTIPATH)	+= dm-multipath.o dm-round-robin.o

obj-$(CONFIG_DM_MULTIPATH_QL)	+= dm-queue-length.o

obj-$(CONFIG_DM_MULTIPATH_ST)	+= dm-service-time.o

obj-$(CONFIG_DM_SNAPSHOT)	+= dm-snapshot.o

obj-$(CONFIG_DM_MIRROR)		+= dm-mirror.o dm-log.o dm-region-hash.o

obj-$(CONFIG_DM_LOG_USERSPACE)	+= dm-log-userspace.o

obj-$(CONFIG_DM_ZERO)		+= dm-zero.o



quiet_cmd_unroll = UNROLL  $@

CRA Git | Maintained and supported by SUSTech CRA and CCSE