dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2010-2011 Neil Brown
|
2018-09-07 02:02:54 +08:00
|
|
|
* Copyright (C) 2010-2018 Red Hat, Inc. All rights reserved.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*
|
|
|
|
* This file is released under the GPL.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/slab.h>
|
2011-07-04 01:58:33 +08:00
|
|
|
#include <linux/module.h>
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
#include "md.h"
|
2011-08-02 19:32:07 +08:00
|
|
|
#include "raid1.h"
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
#include "raid5.h"
|
2012-08-01 10:44:26 +08:00
|
|
|
#include "raid10.h"
|
2017-10-11 05:02:41 +08:00
|
|
|
#include "md-bitmap.h"
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2011-08-02 19:32:03 +08:00
|
|
|
#include <linux/device-mapper.h>
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
#define DM_MSG_PREFIX "raid"
|
2016-05-20 00:49:25 +08:00
|
|
|
#define MAX_RAID_DEVICES 253 /* md-raid kernel limit */
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/*
|
|
|
|
* Minimum sectors of free reshape space per raid device
|
|
|
|
*/
|
|
|
|
#define MIN_FREE_RESHAPE_SPACE to_sector(4*4096)
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/*
|
|
|
|
* Minimum journal space 4 MiB in sectors.
|
|
|
|
*/
|
|
|
|
#define MIN_RAID456_JOURNAL_SPACE (4*2048)
|
|
|
|
|
2014-09-24 23:47:19 +08:00
|
|
|
static bool devices_handle_discard_safely = false;
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/*
|
2011-08-02 19:32:07 +08:00
|
|
|
* The following flags are used by dm-raid.c to set up the array state.
|
|
|
|
* They must be cleared before md_run is called.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-05-31 01:03:37 +08:00
|
|
|
#define FirstUse 10 /* rdev flag */
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
struct raid_dev {
|
|
|
|
/*
|
|
|
|
* Two DM devices, one to hold metadata and one to hold the
|
2016-05-31 01:03:37 +08:00
|
|
|
* actual data/parity. The reason for this is to not confuse
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* ti->len and give more flexibility in altering size and
|
|
|
|
* characteristics.
|
|
|
|
*
|
|
|
|
* While it is possible for this device to be associated
|
|
|
|
* with a different physical device than the data_dev, it
|
|
|
|
* is intended for it to be the same.
|
|
|
|
* |--------- Physical Device ---------|
|
|
|
|
* |- meta_dev -|------ data_dev ------|
|
|
|
|
*/
|
|
|
|
struct dm_dev *meta_dev;
|
|
|
|
struct dm_dev *data_dev;
|
2011-10-11 13:45:26 +08:00
|
|
|
struct md_rdev rdev;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2016-06-03 00:27:46 +08:00
|
|
|
* Bits for establishing rs->ctr_flags
|
2016-05-20 00:49:26 +08:00
|
|
|
*
|
|
|
|
* 1 = no flag value
|
|
|
|
* 2 = flag with value
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-06-03 00:27:46 +08:00
|
|
|
#define __CTR_FLAG_SYNC 0 /* 1 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_NOSYNC 1 /* 1 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_REBUILD 2 /* 2 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_DAEMON_SLEEP 3 /* 2 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_MIN_RECOVERY_RATE 4 /* 2 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_MAX_RECOVERY_RATE 5 /* 2 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_MAX_WRITE_BEHIND 6 /* 2 */ /* Only with raid1! */
|
|
|
|
#define __CTR_FLAG_WRITE_MOSTLY 7 /* 2 */ /* Only with raid1! */
|
|
|
|
#define __CTR_FLAG_STRIPE_CACHE 8 /* 2 */ /* Only with raid4/5/6! */
|
|
|
|
#define __CTR_FLAG_REGION_SIZE 9 /* 2 */ /* Not with raid0! */
|
|
|
|
#define __CTR_FLAG_RAID10_COPIES 10 /* 2 */ /* Only with raid10 */
|
|
|
|
#define __CTR_FLAG_RAID10_FORMAT 11 /* 2 */ /* Only with raid10 */
|
2016-06-02 23:48:09 +08:00
|
|
|
/* New for v1.9.0 */
|
2016-07-07 00:29:22 +08:00
|
|
|
#define __CTR_FLAG_DELTA_DISKS 12 /* 2 */ /* Only with reshapable raid1/4/5/6/10! */
|
2016-06-03 00:27:46 +08:00
|
|
|
#define __CTR_FLAG_DATA_OFFSET 13 /* 2 */ /* Only with reshapable raid4/5/6/10! */
|
|
|
|
#define __CTR_FLAG_RAID10_USE_NEAR_SETS 14 /* 2 */ /* Only with raid10! */
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/* New for v1.10.0 */
|
2017-03-23 00:44:38 +08:00
|
|
|
#define __CTR_FLAG_JOURNAL_DEV 15 /* 2 */ /* Only with raid4/5/6 (journal device)! */
|
|
|
|
|
|
|
|
/* New for v1.11.1 */
|
|
|
|
#define __CTR_FLAG_JOURNAL_MODE 16 /* 2 */ /* Only with raid4/5/6 (journal mode)! */
|
2016-12-01 05:31:05 +08:00
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
/*
|
|
|
|
* Flags for rs->ctr_flags field.
|
|
|
|
*/
|
|
|
|
#define CTR_FLAG_SYNC (1 << __CTR_FLAG_SYNC)
|
|
|
|
#define CTR_FLAG_NOSYNC (1 << __CTR_FLAG_NOSYNC)
|
|
|
|
#define CTR_FLAG_REBUILD (1 << __CTR_FLAG_REBUILD)
|
|
|
|
#define CTR_FLAG_DAEMON_SLEEP (1 << __CTR_FLAG_DAEMON_SLEEP)
|
|
|
|
#define CTR_FLAG_MIN_RECOVERY_RATE (1 << __CTR_FLAG_MIN_RECOVERY_RATE)
|
|
|
|
#define CTR_FLAG_MAX_RECOVERY_RATE (1 << __CTR_FLAG_MAX_RECOVERY_RATE)
|
|
|
|
#define CTR_FLAG_MAX_WRITE_BEHIND (1 << __CTR_FLAG_MAX_WRITE_BEHIND)
|
|
|
|
#define CTR_FLAG_WRITE_MOSTLY (1 << __CTR_FLAG_WRITE_MOSTLY)
|
|
|
|
#define CTR_FLAG_STRIPE_CACHE (1 << __CTR_FLAG_STRIPE_CACHE)
|
|
|
|
#define CTR_FLAG_REGION_SIZE (1 << __CTR_FLAG_REGION_SIZE)
|
|
|
|
#define CTR_FLAG_RAID10_COPIES (1 << __CTR_FLAG_RAID10_COPIES)
|
|
|
|
#define CTR_FLAG_RAID10_FORMAT (1 << __CTR_FLAG_RAID10_FORMAT)
|
|
|
|
#define CTR_FLAG_DELTA_DISKS (1 << __CTR_FLAG_DELTA_DISKS)
|
|
|
|
#define CTR_FLAG_DATA_OFFSET (1 << __CTR_FLAG_DATA_OFFSET)
|
|
|
|
#define CTR_FLAG_RAID10_USE_NEAR_SETS (1 << __CTR_FLAG_RAID10_USE_NEAR_SETS)
|
2016-12-01 05:31:05 +08:00
|
|
|
#define CTR_FLAG_JOURNAL_DEV (1 << __CTR_FLAG_JOURNAL_DEV)
|
2017-03-23 00:44:38 +08:00
|
|
|
#define CTR_FLAG_JOURNAL_MODE (1 << __CTR_FLAG_JOURNAL_MODE)
|
2012-08-01 10:44:26 +08:00
|
|
|
|
2016-05-20 00:49:27 +08:00
|
|
|
/*
|
|
|
|
* Definitions of various constructor flags to
|
|
|
|
* be used in checks of valid / invalid flags
|
|
|
|
* per raid level.
|
|
|
|
*/
|
|
|
|
/* Define all any sync flags */
|
|
|
|
#define CTR_FLAGS_ANY_SYNC (CTR_FLAG_SYNC | CTR_FLAG_NOSYNC)
|
|
|
|
|
|
|
|
/* Define flags for options without argument (e.g. 'nosync') */
|
2016-05-20 00:49:30 +08:00
|
|
|
#define CTR_FLAG_OPTIONS_NO_ARGS (CTR_FLAGS_ANY_SYNC | \
|
|
|
|
CTR_FLAG_RAID10_USE_NEAR_SETS)
|
2016-05-20 00:49:27 +08:00
|
|
|
|
|
|
|
/* Define flags for options with one argument (e.g. 'delta_disks +2') */
|
|
|
|
#define CTR_FLAG_OPTIONS_ONE_ARG (CTR_FLAG_REBUILD | \
|
|
|
|
CTR_FLAG_WRITE_MOSTLY | \
|
|
|
|
CTR_FLAG_DAEMON_SLEEP | \
|
|
|
|
CTR_FLAG_MIN_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_WRITE_BEHIND | \
|
|
|
|
CTR_FLAG_STRIPE_CACHE | \
|
|
|
|
CTR_FLAG_REGION_SIZE | \
|
|
|
|
CTR_FLAG_RAID10_COPIES | \
|
2016-05-20 00:49:30 +08:00
|
|
|
CTR_FLAG_RAID10_FORMAT | \
|
|
|
|
CTR_FLAG_DELTA_DISKS | \
|
2019-12-20 00:58:46 +08:00
|
|
|
CTR_FLAG_DATA_OFFSET | \
|
|
|
|
CTR_FLAG_JOURNAL_DEV | \
|
|
|
|
CTR_FLAG_JOURNAL_MODE)
|
2016-05-20 00:49:27 +08:00
|
|
|
|
2016-06-09 22:42:16 +08:00
|
|
|
/* Valid options definitions per raid level... */
|
|
|
|
|
|
|
|
/* "raid0" does only accept data offset */
|
|
|
|
#define RAID0_VALID_FLAGS (CTR_FLAG_DATA_OFFSET)
|
|
|
|
|
|
|
|
/* "raid1" does not accept stripe cache, data offset, delta_disks or any raid10 options */
|
|
|
|
#define RAID1_VALID_FLAGS (CTR_FLAGS_ANY_SYNC | \
|
|
|
|
CTR_FLAG_REBUILD | \
|
|
|
|
CTR_FLAG_WRITE_MOSTLY | \
|
|
|
|
CTR_FLAG_DAEMON_SLEEP | \
|
|
|
|
CTR_FLAG_MIN_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_WRITE_BEHIND | \
|
|
|
|
CTR_FLAG_REGION_SIZE | \
|
2016-06-30 19:57:08 +08:00
|
|
|
CTR_FLAG_DELTA_DISKS | \
|
2016-06-09 22:42:16 +08:00
|
|
|
CTR_FLAG_DATA_OFFSET)
|
2016-05-20 00:49:27 +08:00
|
|
|
|
2016-06-09 22:42:16 +08:00
|
|
|
/* "raid10" does not accept any raid1 or stripe cache options */
|
|
|
|
#define RAID10_VALID_FLAGS (CTR_FLAGS_ANY_SYNC | \
|
|
|
|
CTR_FLAG_REBUILD | \
|
|
|
|
CTR_FLAG_DAEMON_SLEEP | \
|
|
|
|
CTR_FLAG_MIN_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_REGION_SIZE | \
|
2016-05-20 00:49:27 +08:00
|
|
|
CTR_FLAG_RAID10_COPIES | \
|
2016-05-20 00:49:30 +08:00
|
|
|
CTR_FLAG_RAID10_FORMAT | \
|
|
|
|
CTR_FLAG_DELTA_DISKS | \
|
2016-06-09 22:42:16 +08:00
|
|
|
CTR_FLAG_DATA_OFFSET | \
|
|
|
|
CTR_FLAG_RAID10_USE_NEAR_SETS)
|
2016-05-20 00:49:27 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* "raid4/5/6" do not accept any raid1 or raid10 specific options
|
|
|
|
*
|
|
|
|
* "raid6" does not accept "nosync", because it is not guaranteed
|
|
|
|
* that both parity and q-syndrome are being written properly with
|
|
|
|
* any writes
|
|
|
|
*/
|
2016-06-09 22:42:16 +08:00
|
|
|
#define RAID45_VALID_FLAGS (CTR_FLAGS_ANY_SYNC | \
|
|
|
|
CTR_FLAG_REBUILD | \
|
|
|
|
CTR_FLAG_DAEMON_SLEEP | \
|
|
|
|
CTR_FLAG_MIN_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_STRIPE_CACHE | \
|
|
|
|
CTR_FLAG_REGION_SIZE | \
|
|
|
|
CTR_FLAG_DELTA_DISKS | \
|
2016-12-01 05:31:05 +08:00
|
|
|
CTR_FLAG_DATA_OFFSET | \
|
2017-03-23 00:44:38 +08:00
|
|
|
CTR_FLAG_JOURNAL_DEV | \
|
|
|
|
CTR_FLAG_JOURNAL_MODE)
|
2016-06-09 22:42:16 +08:00
|
|
|
|
|
|
|
#define RAID6_VALID_FLAGS (CTR_FLAG_SYNC | \
|
|
|
|
CTR_FLAG_REBUILD | \
|
|
|
|
CTR_FLAG_DAEMON_SLEEP | \
|
|
|
|
CTR_FLAG_MIN_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_MAX_RECOVERY_RATE | \
|
|
|
|
CTR_FLAG_STRIPE_CACHE | \
|
|
|
|
CTR_FLAG_REGION_SIZE | \
|
|
|
|
CTR_FLAG_DELTA_DISKS | \
|
2016-12-01 05:31:05 +08:00
|
|
|
CTR_FLAG_DATA_OFFSET | \
|
2017-03-23 00:44:38 +08:00
|
|
|
CTR_FLAG_JOURNAL_DEV | \
|
|
|
|
CTR_FLAG_JOURNAL_MODE)
|
2016-06-09 22:42:16 +08:00
|
|
|
/* ...valid options definitions per raid level */
|
2016-05-20 00:49:27 +08:00
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/*
|
|
|
|
* Flags for rs->runtime_flags field
|
|
|
|
* (RT_FLAG prefix meaning "runtime flag")
|
|
|
|
*
|
|
|
|
* These are all internal and used to define runtime state,
|
|
|
|
* e.g. to prevent another resume from preresume processing
|
|
|
|
* the raid set all over again.
|
|
|
|
*/
|
2016-06-13 23:55:13 +08:00
|
|
|
#define RT_FLAG_RS_PRERESUMED 0
|
|
|
|
#define RT_FLAG_RS_RESUMED 1
|
|
|
|
#define RT_FLAG_RS_BITMAP_LOADED 2
|
|
|
|
#define RT_FLAG_UPDATE_SBS 3
|
2016-06-13 23:55:14 +08:00
|
|
|
#define RT_FLAG_RESHAPE_RS 4
|
2017-07-13 23:34:24 +08:00
|
|
|
#define RT_FLAG_RS_SUSPENDED 5
|
2017-12-02 08:03:54 +08:00
|
|
|
#define RT_FLAG_RS_IN_SYNC 6
|
2017-12-02 08:03:55 +08:00
|
|
|
#define RT_FLAG_RS_RESYNCING 7
|
2019-10-01 23:47:53 +08:00
|
|
|
#define RT_FLAG_RS_GROW 8
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-07-07 00:29:22 +08:00
|
|
|
/* Array elements of 64 bit needed for rebuild/failed disk bits */
|
2016-05-20 00:49:30 +08:00
|
|
|
#define DISKS_ARRAY_ELEMS ((MAX_RAID_DEVICES + (sizeof(uint64_t) * 8 - 1)) / sizeof(uint64_t) / 8)
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/*
|
|
|
|
* raid set level, layout and chunk sectors backup/restore
|
|
|
|
*/
|
|
|
|
struct rs_layout {
|
|
|
|
int new_level;
|
|
|
|
int new_layout;
|
|
|
|
int new_chunk_sectors;
|
|
|
|
};
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
struct raid_set {
|
|
|
|
struct dm_target *ti;
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
uint32_t stripe_cache_entries;
|
2016-06-03 00:27:46 +08:00
|
|
|
unsigned long ctr_flags;
|
|
|
|
unsigned long runtime_flags;
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
uint64_t rebuild_disks[DISKS_ARRAY_ELEMS];
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
int raid_disks;
|
|
|
|
int delta_disks;
|
2016-05-20 00:49:31 +08:00
|
|
|
int data_offset;
|
2016-05-20 00:49:30 +08:00
|
|
|
int raid10_copies;
|
2016-06-14 07:46:03 +08:00
|
|
|
int requested_bitmap_chunk_sectors;
|
2016-05-20 00:49:30 +08:00
|
|
|
|
2011-10-11 13:47:53 +08:00
|
|
|
struct mddev md;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
struct raid_type *raid_type;
|
|
|
|
|
2019-10-01 23:47:53 +08:00
|
|
|
sector_t array_sectors;
|
|
|
|
sector_t dev_sectors;
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/* Optional raid4/5/6 journal device */
|
|
|
|
struct journal_dev {
|
|
|
|
struct dm_dev *dev;
|
|
|
|
struct md_rdev rdev;
|
2017-03-23 00:44:38 +08:00
|
|
|
int mode;
|
2016-12-01 05:31:05 +08:00
|
|
|
} journal_dev;
|
|
|
|
|
2020-05-08 02:51:58 +08:00
|
|
|
struct raid_dev dev[];
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
};
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
static void rs_config_backup(struct raid_set *rs, struct rs_layout *l)
|
2016-05-20 00:49:33 +08:00
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
l->new_level = mddev->new_level;
|
|
|
|
l->new_layout = mddev->new_layout;
|
|
|
|
l->new_chunk_sectors = mddev->new_chunk_sectors;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
static void rs_config_restore(struct raid_set *rs, struct rs_layout *l)
|
2016-05-20 00:49:33 +08:00
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
mddev->new_level = l->new_level;
|
|
|
|
mddev->new_layout = l->new_layout;
|
|
|
|
mddev->new_chunk_sectors = l->new_chunk_sectors;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* raid10 algorithms (i.e. formats) */
|
|
|
|
#define ALGORITHM_RAID10_DEFAULT 0
|
|
|
|
#define ALGORITHM_RAID10_NEAR 1
|
|
|
|
#define ALGORITHM_RAID10_OFFSET 2
|
|
|
|
#define ALGORITHM_RAID10_FAR 3
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/* Supported raid types and properties. */
|
|
|
|
static struct raid_type {
|
|
|
|
const char *name; /* RAID algorithm. */
|
|
|
|
const char *descr; /* Descriptor text for logging. */
|
2016-07-19 20:03:51 +08:00
|
|
|
const unsigned int parity_devs; /* # of parity devices. */
|
|
|
|
const unsigned int minimal_devs;/* minimal # of devices in set. */
|
|
|
|
const unsigned int level; /* RAID level. */
|
|
|
|
const unsigned int algorithm; /* RAID algorithm. */
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
} raid_types[] = {
|
2016-05-31 01:03:37 +08:00
|
|
|
{"raid0", "raid0 (striping)", 0, 2, 0, 0 /* NONE */},
|
|
|
|
{"raid1", "raid1 (mirroring)", 0, 2, 1, 0 /* NONE */},
|
|
|
|
{"raid10_far", "raid10 far (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_FAR},
|
2016-05-20 00:49:30 +08:00
|
|
|
{"raid10_offset", "raid10 offset (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_OFFSET},
|
2016-05-31 01:03:37 +08:00
|
|
|
{"raid10_near", "raid10 near (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_NEAR},
|
|
|
|
{"raid10", "raid10 (striped mirrors)", 0, 2, 10, ALGORITHM_RAID10_DEFAULT},
|
2016-10-18 03:20:07 +08:00
|
|
|
{"raid4", "raid4 (dedicated first parity disk)", 1, 2, 5, ALGORITHM_PARITY_0}, /* raid4 layout = raid5_0 */
|
2016-05-31 01:03:37 +08:00
|
|
|
{"raid5_n", "raid5 (dedicated last parity disk)", 1, 2, 5, ALGORITHM_PARITY_N},
|
|
|
|
{"raid5_ls", "raid5 (left symmetric)", 1, 2, 5, ALGORITHM_LEFT_SYMMETRIC},
|
|
|
|
{"raid5_rs", "raid5 (right symmetric)", 1, 2, 5, ALGORITHM_RIGHT_SYMMETRIC},
|
|
|
|
{"raid5_la", "raid5 (left asymmetric)", 1, 2, 5, ALGORITHM_LEFT_ASYMMETRIC},
|
|
|
|
{"raid5_ra", "raid5 (right asymmetric)", 1, 2, 5, ALGORITHM_RIGHT_ASYMMETRIC},
|
|
|
|
{"raid6_zr", "raid6 (zero restart)", 2, 4, 6, ALGORITHM_ROTATING_ZERO_RESTART},
|
|
|
|
{"raid6_nr", "raid6 (N restart)", 2, 4, 6, ALGORITHM_ROTATING_N_RESTART},
|
|
|
|
{"raid6_nc", "raid6 (N continue)", 2, 4, 6, ALGORITHM_ROTATING_N_CONTINUE},
|
|
|
|
{"raid6_n_6", "raid6 (dedicated parity/Q n/6)", 2, 4, 6, ALGORITHM_PARITY_N_6},
|
|
|
|
{"raid6_ls_6", "raid6 (left symmetric dedicated Q 6)", 2, 4, 6, ALGORITHM_LEFT_SYMMETRIC_6},
|
|
|
|
{"raid6_rs_6", "raid6 (right symmetric dedicated Q 6)", 2, 4, 6, ALGORITHM_RIGHT_SYMMETRIC_6},
|
|
|
|
{"raid6_la_6", "raid6 (left asymmetric dedicated Q 6)", 2, 4, 6, ALGORITHM_LEFT_ASYMMETRIC_6},
|
|
|
|
{"raid6_ra_6", "raid6 (right asymmetric dedicated Q 6)", 2, 4, 6, ALGORITHM_RIGHT_ASYMMETRIC_6}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
};
|
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
/* True, if @v is in inclusive range [@min, @max] */
|
2016-06-03 00:06:54 +08:00
|
|
|
static bool __within_range(long v, long min, long max)
|
2016-05-20 00:49:25 +08:00
|
|
|
{
|
|
|
|
return v >= min && v <= max;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:26 +08:00
|
|
|
/* All table line arguments are defined here */
|
|
|
|
static struct arg_name_flag {
|
2016-06-03 00:27:46 +08:00
|
|
|
const unsigned long flag;
|
2016-05-20 00:49:26 +08:00
|
|
|
const char *name;
|
2016-06-03 03:27:22 +08:00
|
|
|
} __arg_name_flags[] = {
|
2016-05-20 00:49:26 +08:00
|
|
|
{ CTR_FLAG_SYNC, "sync"},
|
|
|
|
{ CTR_FLAG_NOSYNC, "nosync"},
|
|
|
|
{ CTR_FLAG_REBUILD, "rebuild"},
|
|
|
|
{ CTR_FLAG_DAEMON_SLEEP, "daemon_sleep"},
|
|
|
|
{ CTR_FLAG_MIN_RECOVERY_RATE, "min_recovery_rate"},
|
|
|
|
{ CTR_FLAG_MAX_RECOVERY_RATE, "max_recovery_rate"},
|
|
|
|
{ CTR_FLAG_MAX_WRITE_BEHIND, "max_write_behind"},
|
2016-06-25 03:32:25 +08:00
|
|
|
{ CTR_FLAG_WRITE_MOSTLY, "write_mostly"},
|
2016-05-20 00:49:26 +08:00
|
|
|
{ CTR_FLAG_STRIPE_CACHE, "stripe_cache"},
|
|
|
|
{ CTR_FLAG_REGION_SIZE, "region_size"},
|
|
|
|
{ CTR_FLAG_RAID10_COPIES, "raid10_copies"},
|
|
|
|
{ CTR_FLAG_RAID10_FORMAT, "raid10_format"},
|
2016-05-20 00:49:31 +08:00
|
|
|
{ CTR_FLAG_DATA_OFFSET, "data_offset"},
|
|
|
|
{ CTR_FLAG_DELTA_DISKS, "delta_disks"},
|
|
|
|
{ CTR_FLAG_RAID10_USE_NEAR_SETS, "raid10_use_near_sets"},
|
2016-12-01 05:31:05 +08:00
|
|
|
{ CTR_FLAG_JOURNAL_DEV, "journal_dev" },
|
2017-03-23 00:44:38 +08:00
|
|
|
{ CTR_FLAG_JOURNAL_MODE, "journal_mode" },
|
2016-05-20 00:49:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Return argument name string for given @flag */
|
2016-06-02 23:58:51 +08:00
|
|
|
static const char *dm_raid_arg_name_by_flag(const uint32_t flag)
|
2016-05-20 00:49:26 +08:00
|
|
|
{
|
|
|
|
if (hweight32(flag) == 1) {
|
2016-06-03 03:27:22 +08:00
|
|
|
struct arg_name_flag *anf = __arg_name_flags + ARRAY_SIZE(__arg_name_flags);
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-03 03:27:22 +08:00
|
|
|
while (anf-- > __arg_name_flags)
|
2016-06-03 00:27:46 +08:00
|
|
|
if (flag & anf->flag)
|
2016-05-20 00:49:26 +08:00
|
|
|
return anf->name;
|
|
|
|
|
|
|
|
} else
|
|
|
|
DMERR("%s called with more than one flag!", __func__);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-03-23 00:44:38 +08:00
|
|
|
/* Define correlation of raid456 journal cache modes and dm-raid target line parameters */
|
|
|
|
static struct {
|
|
|
|
const int mode;
|
|
|
|
const char *param;
|
|
|
|
} _raid456_journal_mode[] = {
|
|
|
|
{ R5C_JOURNAL_MODE_WRITE_THROUGH , "writethrough" },
|
|
|
|
{ R5C_JOURNAL_MODE_WRITE_BACK , "writeback" }
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Return MD raid4/5/6 journal mode for dm @journal_mode one */
|
|
|
|
static int dm_raid_journal_mode_to_md(const char *mode)
|
|
|
|
{
|
|
|
|
int m = ARRAY_SIZE(_raid456_journal_mode);
|
|
|
|
|
|
|
|
while (m--)
|
|
|
|
if (!strcasecmp(mode, _raid456_journal_mode[m].param))
|
|
|
|
return _raid456_journal_mode[m].mode;
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return dm-raid raid4/5/6 journal mode string for @mode */
|
|
|
|
static const char *md_journal_mode_to_dm_raid(const int mode)
|
|
|
|
{
|
|
|
|
int m = ARRAY_SIZE(_raid456_journal_mode);
|
|
|
|
|
|
|
|
while (m--)
|
|
|
|
if (mode == _raid456_journal_mode[m].mode)
|
|
|
|
return _raid456_journal_mode[m].param;
|
|
|
|
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/*
|
2016-07-07 00:29:22 +08:00
|
|
|
* Bool helpers to test for various raid levels of a raid set.
|
|
|
|
* It's level as reported by the superblock rather than
|
2016-05-20 00:49:30 +08:00
|
|
|
* the requested raid_type passed to the constructor.
|
|
|
|
*/
|
|
|
|
/* Return true, if raid set in @rs is raid0 */
|
|
|
|
static bool rs_is_raid0(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return !rs->md.level;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/* Return true, if raid set in @rs is raid1 */
|
|
|
|
static bool rs_is_raid1(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.level == 1;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Return true, if raid set in @rs is raid10 */
|
|
|
|
static bool rs_is_raid10(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.level == 10;
|
|
|
|
}
|
|
|
|
|
2016-06-24 06:21:09 +08:00
|
|
|
/* Return true, if raid set in @rs is level 6 */
|
|
|
|
static bool rs_is_raid6(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.level == 6;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/* Return true, if raid set in @rs is level 4, 5 or 6 */
|
|
|
|
static bool rs_is_raid456(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return __within_range(rs->md.level, 4, 6);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid set in @rs is reshapable */
|
2016-07-07 00:29:22 +08:00
|
|
|
static bool __is_raid10_far(int layout);
|
2016-06-13 23:55:13 +08:00
|
|
|
static bool rs_is_reshapable(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs_is_raid456(rs) ||
|
|
|
|
(rs_is_raid10(rs) && !__is_raid10_far(rs->md.new_layout));
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/* Return true, if raid set in @rs is recovering */
|
|
|
|
static bool rs_is_recovering(struct raid_set *rs)
|
|
|
|
{
|
2017-01-14 10:53:08 +08:00
|
|
|
return rs->md.recovery_cp < rs->md.dev_sectors;
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid set in @rs is reshaping */
|
|
|
|
static bool rs_is_reshaping(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.reshape_position != MaxSector;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:27 +08:00
|
|
|
/*
|
2016-07-07 00:29:22 +08:00
|
|
|
* bool helpers to test for various raid levels of a raid type @rt
|
2016-05-20 00:49:27 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid0 */
|
|
|
|
static bool rt_is_raid0(struct raid_type *rt)
|
|
|
|
{
|
|
|
|
return !rt->level;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid1 */
|
|
|
|
static bool rt_is_raid1(struct raid_type *rt)
|
|
|
|
{
|
|
|
|
return rt->level == 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid10 */
|
|
|
|
static bool rt_is_raid10(struct raid_type *rt)
|
|
|
|
{
|
|
|
|
return rt->level == 10;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid4/5 */
|
|
|
|
static bool rt_is_raid45(struct raid_type *rt)
|
|
|
|
{
|
2016-06-03 00:06:54 +08:00
|
|
|
return __within_range(rt->level, 4, 5);
|
2016-05-20 00:49:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid6 */
|
|
|
|
static bool rt_is_raid6(struct raid_type *rt)
|
|
|
|
{
|
|
|
|
return rt->level == 6;
|
|
|
|
}
|
2016-05-20 00:49:29 +08:00
|
|
|
|
|
|
|
/* Return true, if raid type in @rt is raid4/5/6 */
|
|
|
|
static bool rt_is_raid456(struct raid_type *rt)
|
|
|
|
{
|
2016-06-03 00:06:54 +08:00
|
|
|
return __within_range(rt->level, 4, 6);
|
2016-05-20 00:49:29 +08:00
|
|
|
}
|
2016-05-20 00:49:27 +08:00
|
|
|
/* END: raid level bools */
|
|
|
|
|
2016-06-09 22:42:16 +08:00
|
|
|
/* Return valid ctr flags for the raid level of @rs */
|
|
|
|
static unsigned long __valid_flags(struct raid_set *rs)
|
2016-05-20 00:49:27 +08:00
|
|
|
{
|
|
|
|
if (rt_is_raid0(rs->raid_type))
|
2016-06-09 22:42:16 +08:00
|
|
|
return RAID0_VALID_FLAGS;
|
2016-05-20 00:49:27 +08:00
|
|
|
else if (rt_is_raid1(rs->raid_type))
|
2016-06-09 22:42:16 +08:00
|
|
|
return RAID1_VALID_FLAGS;
|
2016-05-20 00:49:27 +08:00
|
|
|
else if (rt_is_raid10(rs->raid_type))
|
2016-06-09 22:42:16 +08:00
|
|
|
return RAID10_VALID_FLAGS;
|
2016-05-20 00:49:27 +08:00
|
|
|
else if (rt_is_raid45(rs->raid_type))
|
2016-06-09 22:42:16 +08:00
|
|
|
return RAID45_VALID_FLAGS;
|
2016-05-20 00:49:27 +08:00
|
|
|
else if (rt_is_raid6(rs->raid_type))
|
2016-06-09 22:42:16 +08:00
|
|
|
return RAID6_VALID_FLAGS;
|
2016-05-20 00:49:27 +08:00
|
|
|
|
2016-07-07 00:29:22 +08:00
|
|
|
return 0;
|
2016-05-20 00:49:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2016-06-09 22:42:16 +08:00
|
|
|
* Check for valid flags set on @rs
|
2016-05-20 00:49:27 +08:00
|
|
|
*
|
|
|
|
* Has to be called after parsing of the ctr flags!
|
|
|
|
*/
|
2016-06-09 22:42:16 +08:00
|
|
|
static int rs_check_for_valid_flags(struct raid_set *rs)
|
2016-05-20 00:49:27 +08:00
|
|
|
{
|
2016-06-09 22:42:16 +08:00
|
|
|
if (rs->ctr_flags & ~__valid_flags(rs)) {
|
2016-06-03 00:27:46 +08:00
|
|
|
rs->ti->error = "Invalid flags combination";
|
2016-06-01 02:26:52 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:27 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* MD raid10 bit definitions and helpers */
|
|
|
|
#define RAID10_OFFSET (1 << 16) /* stripes with data copies area adjacent on devices */
|
|
|
|
#define RAID10_BROCKEN_USE_FAR_SETS (1 << 17) /* Broken in raid10.c: use sets instead of whole stripe rotation */
|
|
|
|
#define RAID10_USE_FAR_SETS (1 << 18) /* Use sets instead of whole stripe rotation */
|
|
|
|
#define RAID10_FAR_COPIES_SHIFT 8 /* raid10 # far copies shift (2nd byte of layout) */
|
|
|
|
|
|
|
|
/* Return md raid10 near copies for @layout */
|
2016-06-03 03:27:22 +08:00
|
|
|
static unsigned int __raid10_near_copies(int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
|
|
|
return layout & 0xFF;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return md raid10 far copies for @layout */
|
2016-06-03 03:27:22 +08:00
|
|
|
static unsigned int __raid10_far_copies(int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
2016-06-03 03:27:22 +08:00
|
|
|
return __raid10_near_copies(layout >> RAID10_FAR_COPIES_SHIFT);
|
2016-05-20 00:49:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true if md raid10 offset for @layout */
|
2016-07-07 00:29:22 +08:00
|
|
|
static bool __is_raid10_offset(int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
2016-07-07 00:29:22 +08:00
|
|
|
return !!(layout & RAID10_OFFSET);
|
2016-05-20 00:49:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true if md raid10 near for @layout */
|
2016-07-07 00:29:22 +08:00
|
|
|
static bool __is_raid10_near(int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
2016-06-03 03:27:22 +08:00
|
|
|
return !__is_raid10_offset(layout) && __raid10_near_copies(layout) > 1;
|
2016-05-20 00:49:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return true if md raid10 far for @layout */
|
2016-07-07 00:29:22 +08:00
|
|
|
static bool __is_raid10_far(int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
2016-06-03 03:27:22 +08:00
|
|
|
return !__is_raid10_offset(layout) && __raid10_far_copies(layout) > 1;
|
2016-05-20 00:49:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return md raid10 layout string for @layout */
|
|
|
|
static const char *raid10_md_layout_to_format(int layout)
|
2013-02-21 10:28:10 +08:00
|
|
|
{
|
|
|
|
/*
|
2016-05-20 00:49:30 +08:00
|
|
|
* Bit 16 stands for "offset"
|
|
|
|
* (i.e. adjacent stripes hold copies)
|
|
|
|
*
|
2013-02-21 10:28:10 +08:00
|
|
|
* Refer to MD's raid10.c for details
|
|
|
|
*/
|
2016-06-03 03:27:22 +08:00
|
|
|
if (__is_raid10_offset(layout))
|
2013-02-21 10:28:10 +08:00
|
|
|
return "offset";
|
|
|
|
|
2016-06-03 03:27:22 +08:00
|
|
|
if (__raid10_near_copies(layout) > 1)
|
2013-02-21 10:28:10 +08:00
|
|
|
return "near";
|
|
|
|
|
2017-07-13 23:33:22 +08:00
|
|
|
if (__raid10_far_copies(layout) > 1)
|
|
|
|
return "far";
|
2016-05-20 00:49:30 +08:00
|
|
|
|
2017-07-13 23:33:22 +08:00
|
|
|
return "unknown";
|
2013-02-21 10:28:10 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Return md raid10 algorithm for @name */
|
2018-06-22 16:01:19 +08:00
|
|
|
static int raid10_name_to_format(const char *name)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
|
|
|
if (!strcasecmp(name, "near"))
|
|
|
|
return ALGORITHM_RAID10_NEAR;
|
|
|
|
else if (!strcasecmp(name, "offset"))
|
|
|
|
return ALGORITHM_RAID10_OFFSET;
|
|
|
|
else if (!strcasecmp(name, "far"))
|
|
|
|
return ALGORITHM_RAID10_FAR;
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return md raid10 copies for @layout */
|
|
|
|
static unsigned int raid10_md_layout_to_copies(int layout)
|
2012-08-01 10:44:26 +08:00
|
|
|
{
|
2016-07-07 00:29:22 +08:00
|
|
|
return max(__raid10_near_copies(layout), __raid10_far_copies(layout));
|
2012-08-01 10:44:26 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Return md raid10 format id for @format string */
|
|
|
|
static int raid10_format_to_md_layout(struct raid_set *rs,
|
|
|
|
unsigned int algorithm,
|
|
|
|
unsigned int copies)
|
2012-08-01 10:44:26 +08:00
|
|
|
{
|
2016-05-20 00:49:30 +08:00
|
|
|
unsigned int n = 1, f = 1, r = 0;
|
2013-02-21 10:28:10 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/*
|
|
|
|
* MD resilienece flaw:
|
|
|
|
*
|
|
|
|
* enabling use_far_sets for far/offset formats causes copies
|
|
|
|
* to be colocated on the same devs together with their origins!
|
|
|
|
*
|
|
|
|
* -> disable it for now in the definition above
|
|
|
|
*/
|
|
|
|
if (algorithm == ALGORITHM_RAID10_DEFAULT ||
|
|
|
|
algorithm == ALGORITHM_RAID10_NEAR)
|
2013-02-21 10:28:10 +08:00
|
|
|
n = copies;
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
else if (algorithm == ALGORITHM_RAID10_OFFSET) {
|
|
|
|
f = copies;
|
|
|
|
r = RAID10_OFFSET;
|
2016-06-03 00:27:46 +08:00
|
|
|
if (!test_bit(__CTR_FLAG_RAID10_USE_NEAR_SETS, &rs->ctr_flags))
|
2016-05-20 00:49:30 +08:00
|
|
|
r |= RAID10_USE_FAR_SETS;
|
|
|
|
|
|
|
|
} else if (algorithm == ALGORITHM_RAID10_FAR) {
|
2013-02-21 10:28:10 +08:00
|
|
|
f = copies;
|
2016-06-03 00:27:46 +08:00
|
|
|
if (!test_bit(__CTR_FLAG_RAID10_USE_NEAR_SETS, &rs->ctr_flags))
|
2016-05-20 00:49:30 +08:00
|
|
|
r |= RAID10_USE_FAR_SETS;
|
2013-02-21 10:28:10 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
} else
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return r | (f << RAID10_FAR_COPIES_SHIFT) | n;
|
|
|
|
}
|
|
|
|
/* END: MD raid10 bit definitions and helpers */
|
2013-02-21 10:28:10 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Check for any of the raid10 algorithms */
|
2016-07-07 00:29:22 +08:00
|
|
|
static bool __got_raid10(struct raid_type *rtp, const int layout)
|
2016-05-20 00:49:30 +08:00
|
|
|
{
|
|
|
|
if (rtp->level == 10) {
|
|
|
|
switch (rtp->algorithm) {
|
|
|
|
case ALGORITHM_RAID10_DEFAULT:
|
|
|
|
case ALGORITHM_RAID10_NEAR:
|
2016-06-03 03:27:22 +08:00
|
|
|
return __is_raid10_near(layout);
|
2016-05-20 00:49:30 +08:00
|
|
|
case ALGORITHM_RAID10_OFFSET:
|
2016-06-03 03:27:22 +08:00
|
|
|
return __is_raid10_offset(layout);
|
2016-05-20 00:49:30 +08:00
|
|
|
case ALGORITHM_RAID10_FAR:
|
2016-06-03 03:27:22 +08:00
|
|
|
return __is_raid10_far(layout);
|
2016-05-20 00:49:30 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2013-02-21 10:28:10 +08:00
|
|
|
|
2016-07-07 00:29:22 +08:00
|
|
|
return false;
|
2012-08-01 10:44:26 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Return raid_type for @name */
|
2016-05-20 00:49:25 +08:00
|
|
|
static struct raid_type *get_raid_type(const char *name)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2016-05-20 00:49:30 +08:00
|
|
|
struct raid_type *rtp = raid_types + ARRAY_SIZE(raid_types);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
while (rtp-- > raid_types)
|
|
|
|
if (!strcasecmp(rtp->name, name))
|
|
|
|
return rtp;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Return raid_type for @name based derived from @level and @layout */
|
|
|
|
static struct raid_type *get_raid_type_by_ll(const int level, const int layout)
|
|
|
|
{
|
|
|
|
struct raid_type *rtp = raid_types + ARRAY_SIZE(raid_types);
|
|
|
|
|
|
|
|
while (rtp-- > raid_types) {
|
|
|
|
/* RAID10 special checks based on @layout flags/properties */
|
|
|
|
if (rtp->level == level &&
|
2016-06-03 03:27:22 +08:00
|
|
|
(__got_raid10(rtp, layout) || rtp->algorithm == layout))
|
2016-05-20 00:49:30 +08:00
|
|
|
return rtp;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:51 +08:00
|
|
|
/* Adjust rdev sectors */
|
|
|
|
static void rs_set_rdev_sectors(struct raid_set *rs)
|
2016-06-13 23:55:14 +08:00
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
2016-06-24 06:36:08 +08:00
|
|
|
struct md_rdev *rdev;
|
2016-06-13 23:55:14 +08:00
|
|
|
|
2016-06-24 06:36:08 +08:00
|
|
|
/*
|
|
|
|
* raid10 sets rdev->sector to the device size, which
|
|
|
|
* is unintended in case of out-of-place reshaping
|
|
|
|
*/
|
|
|
|
rdev_for_each(rdev, mddev)
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags))
|
|
|
|
rdev->sectors = mddev->dev_sectors;
|
2017-12-02 08:03:51 +08:00
|
|
|
}
|
2016-06-24 06:36:08 +08:00
|
|
|
|
2017-12-02 08:03:51 +08:00
|
|
|
/*
|
|
|
|
* Change bdev capacity of @rs in case of a disk add/remove reshape
|
|
|
|
*/
|
|
|
|
static void rs_set_capacity(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct gendisk *gendisk = dm_disk(dm_table_get_md(rs->ti->table));
|
|
|
|
|
2020-11-16 22:57:10 +08:00
|
|
|
set_capacity_and_notify(gendisk, rs->md.array_sectors);
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
|
|
|
* Set the mddev properties in @rs to the current
|
|
|
|
* ones retrieved from the freshest superblock
|
|
|
|
*/
|
|
|
|
static void rs_set_cur(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
mddev->new_level = mddev->level;
|
|
|
|
mddev->new_layout = mddev->layout;
|
|
|
|
mddev->new_chunk_sectors = mddev->chunk_sectors;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/*
|
|
|
|
* Set the mddev properties in @rs to the new
|
|
|
|
* ones requested by the ctr
|
|
|
|
*/
|
|
|
|
static void rs_set_new(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
mddev->level = mddev->new_level;
|
|
|
|
mddev->layout = mddev->new_layout;
|
|
|
|
mddev->chunk_sectors = mddev->new_chunk_sectors;
|
2016-05-20 00:49:34 +08:00
|
|
|
mddev->raid_disks = rs->raid_disks;
|
2016-05-20 00:49:30 +08:00
|
|
|
mddev->delta_disks = 0;
|
|
|
|
}
|
|
|
|
|
2016-06-03 03:08:09 +08:00
|
|
|
static struct raid_set *raid_set_alloc(struct dm_target *ti, struct raid_type *raid_type,
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int raid_devs)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int i;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
struct raid_set *rs;
|
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
if (raid_devs <= raid_type->parity_devs) {
|
|
|
|
ti->error = "Insufficient number of devices";
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
treewide: Use struct_size() for kmalloc()-family
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);
This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
uses. It was done via automatic conversion with manual review for the
"CHECKME" non-standard cases noted below, using the following Coccinelle
script:
// pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
// sizeof *pkey_cache->table, GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@
- alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
// mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@
- alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)
// Same pattern, but can't trivially locate the trailing element name,
// or variable name.
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
expression SOMETHING, COUNT, ELEMENT;
@@
- alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
+ alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-09 04:45:50 +08:00
|
|
|
rs = kzalloc(struct_size(rs, dev, raid_devs), GFP_KERNEL);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rs) {
|
|
|
|
ti->error = "Cannot allocate raid context";
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
mddev_init(&rs->md);
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
rs->raid_disks = raid_devs;
|
|
|
|
rs->delta_disks = 0;
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->ti = ti;
|
|
|
|
rs->raid_type = raid_type;
|
2016-06-13 23:55:14 +08:00
|
|
|
rs->stripe_cache_entries = 256;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->md.raid_disks = raid_devs;
|
|
|
|
rs->md.level = raid_type->level;
|
|
|
|
rs->md.new_level = rs->md.level;
|
|
|
|
rs->md.layout = raid_type->algorithm;
|
|
|
|
rs->md.new_layout = rs->md.layout;
|
|
|
|
rs->md.delta_disks = 0;
|
2016-06-24 06:21:09 +08:00
|
|
|
rs->md.recovery_cp = MaxSector;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
for (i = 0; i < raid_devs; i++)
|
|
|
|
md_rdev_init(&rs->dev[i].rdev);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remaining items to be initialized by further RAID params:
|
|
|
|
* rs->md.persistent
|
|
|
|
* rs->md.external
|
|
|
|
* rs->md.chunk_sectors
|
|
|
|
* rs->md.new_chunk_sectors
|
2012-07-27 22:08:04 +08:00
|
|
|
* rs->md.dev_sectors
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
return rs;
|
|
|
|
}
|
|
|
|
|
2018-09-07 00:33:38 +08:00
|
|
|
/* Free all @rs allocations */
|
2016-06-03 03:08:09 +08:00
|
|
|
static void raid_set_free(struct raid_set *rs)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
if (rs->journal_dev.dev) {
|
|
|
|
md_rdev_clear(&rs->journal_dev.rdev);
|
|
|
|
dm_put_device(rs->ti, rs->journal_dev.dev);
|
|
|
|
}
|
|
|
|
|
2016-06-30 20:37:50 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
2011-08-02 19:32:07 +08:00
|
|
|
if (rs->dev[i].meta_dev)
|
|
|
|
dm_put_device(rs->ti, rs->dev[i].meta_dev);
|
2012-05-22 11:54:30 +08:00
|
|
|
md_rdev_clear(&rs->dev[i].rdev);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
if (rs->dev[i].data_dev)
|
|
|
|
dm_put_device(rs->ti, rs->dev[i].data_dev);
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
kfree(rs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For every device we have two words
|
|
|
|
* <meta_dev>: meta device name or '-' if missing
|
|
|
|
* <data_dev>: data device name or '-' if missing
|
|
|
|
*
|
2011-08-02 19:32:07 +08:00
|
|
|
* The following are permitted:
|
|
|
|
* - -
|
|
|
|
* - <data_dev>
|
|
|
|
* <meta_dev> <data_dev>
|
|
|
|
*
|
|
|
|
* The following is not allowed:
|
|
|
|
* <meta_dev> -
|
|
|
|
*
|
|
|
|
* This code parses those words. If there is a failure,
|
2016-06-03 03:08:09 +08:00
|
|
|
* the caller must use raid_set_free() to unwind the operations.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-05-20 00:49:26 +08:00
|
|
|
static int parse_dev_params(struct raid_set *rs, struct dm_arg_set *as)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int rebuild = 0;
|
|
|
|
int metadata_available = 0;
|
2016-05-20 00:49:24 +08:00
|
|
|
int r = 0;
|
2016-05-20 00:49:25 +08:00
|
|
|
const char *arg;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
/* Put off the number of raid devices argument to get to dev pairs */
|
|
|
|
arg = dm_shift_arg(as);
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-06-30 20:37:50 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->dev[i].rdev.raid_disk = i;
|
|
|
|
|
|
|
|
rs->dev[i].meta_dev = NULL;
|
|
|
|
rs->dev[i].data_dev = NULL;
|
|
|
|
|
|
|
|
/*
|
2016-12-01 05:31:05 +08:00
|
|
|
* There are no offsets initially.
|
|
|
|
* Out of place reshape will set them accordingly.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
|
|
|
rs->dev[i].rdev.data_offset = 0;
|
2016-12-01 05:31:05 +08:00
|
|
|
rs->dev[i].rdev.new_data_offset = 0;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->dev[i].rdev.mddev = &rs->md;
|
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
arg = dm_shift_arg(as);
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (strcmp(arg, "-")) {
|
2016-06-01 02:26:52 +08:00
|
|
|
r = dm_get_device(rs->ti, arg, dm_table_get_mode(rs->ti->table),
|
|
|
|
&rs->dev[i].meta_dev);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "RAID metadata device lookup failure";
|
|
|
|
return r;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
rs->dev[i].rdev.sb_page = alloc_page(GFP_KERNEL);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rs->dev[i].rdev.sb_page) {
|
|
|
|
rs->ti->error = "Failed to allocate superblock page";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
arg = dm_shift_arg(as);
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcmp(arg, "-")) {
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
if (!test_bit(In_sync, &rs->dev[i].rdev.flags) &&
|
2016-06-01 02:26:52 +08:00
|
|
|
(!rs->dev[i].rdev.recovery_offset)) {
|
|
|
|
rs->ti->error = "Drive designated for rebuild not specified";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
if (rs->dev[i].meta_dev) {
|
|
|
|
rs->ti->error = "No data device supplied with metadata device";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
r = dm_get_device(rs->ti, arg, dm_table_get_mode(rs->ti->table),
|
|
|
|
&rs->dev[i].data_dev);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "RAID device lookup failure";
|
|
|
|
return r;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
if (rs->dev[i].meta_dev) {
|
|
|
|
metadata_available = 1;
|
|
|
|
rs->dev[i].rdev.meta_bdev = rs->dev[i].meta_dev->bdev;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->dev[i].rdev.bdev = rs->dev[i].data_dev->bdev;
|
2016-05-20 00:49:34 +08:00
|
|
|
list_add_tail(&rs->dev[i].rdev.same_set, &rs->md.disks);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
if (!test_bit(In_sync, &rs->dev[i].rdev.flags))
|
|
|
|
rebuild++;
|
|
|
|
}
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
if (rs->journal_dev.dev)
|
|
|
|
list_add_tail(&rs->journal_dev.rdev.same_set, &rs->md.disks);
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
if (metadata_available) {
|
|
|
|
rs->md.external = 0;
|
|
|
|
rs->md.persistent = 1;
|
|
|
|
rs->md.major_version = 2;
|
|
|
|
} else if (rebuild && !rs->md.recovery_cp) {
|
|
|
|
/*
|
|
|
|
* Without metadata, we will not be able to tell if the array
|
|
|
|
* is in-sync or not - we must assume it is not. Therefore,
|
|
|
|
* it is impossible to rebuild a drive.
|
|
|
|
*
|
|
|
|
* Even if there is metadata, the on-disk information may
|
|
|
|
* indicate that the array is not in-sync and it will then
|
|
|
|
* fail at that time.
|
|
|
|
*
|
|
|
|
* User could specify 'nosync' option if desperate.
|
|
|
|
*/
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Unable to rebuild drive while array is not in-sync";
|
|
|
|
return -EINVAL;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
/*
|
|
|
|
* validate_region_size
|
|
|
|
* @rs
|
|
|
|
* @region_size: region size in sectors. If 0, pick a size (4MiB default).
|
|
|
|
*
|
|
|
|
* Set rs->md.bitmap_info.chunksize (which really refers to 'region size').
|
|
|
|
* Ensure that (ti->len/region_size < 2^21) - required by MD bitmap.
|
|
|
|
*
|
|
|
|
* Returns: 0 on success, -EINVAL on failure.
|
|
|
|
*/
|
|
|
|
static int validate_region_size(struct raid_set *rs, unsigned long region_size)
|
|
|
|
{
|
|
|
|
unsigned long min_region_size = rs->ti->len / (1 << 21);
|
|
|
|
|
2016-08-17 21:36:44 +08:00
|
|
|
if (rs_is_raid0(rs))
|
|
|
|
return 0;
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
if (!region_size) {
|
|
|
|
/*
|
2016-05-31 01:03:37 +08:00
|
|
|
* Choose a reasonable default. All figures in sectors.
|
2011-08-02 19:32:07 +08:00
|
|
|
*/
|
|
|
|
if (min_region_size > (1 << 13)) {
|
2012-12-22 04:23:33 +08:00
|
|
|
/* If not a power of 2, make it the next power of 2 */
|
2015-10-02 23:17:37 +08:00
|
|
|
region_size = roundup_pow_of_two(min_region_size);
|
2011-08-02 19:32:07 +08:00
|
|
|
DMINFO("Choosing default region size of %lu sectors",
|
|
|
|
region_size);
|
|
|
|
} else {
|
|
|
|
DMINFO("Choosing default region size of 4MiB");
|
|
|
|
region_size = 1 << 13; /* sectors */
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Validate user-supplied value.
|
|
|
|
*/
|
2016-06-01 02:26:52 +08:00
|
|
|
if (region_size > rs->ti->len) {
|
|
|
|
rs->ti->error = "Supplied region size is too large";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
if (region_size < min_region_size) {
|
|
|
|
DMERR("Supplied region_size (%lu sectors) below minimum (%lu)",
|
|
|
|
region_size, min_region_size);
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Supplied region size is too small";
|
|
|
|
return -EINVAL;
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!is_power_of_2(region_size)) {
|
|
|
|
rs->ti->error = "Region size is not a power of 2";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
if (region_size < rs->md.chunk_sectors) {
|
|
|
|
rs->ti->error = "Region size is smaller than the chunk size";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Convert sectors to bytes.
|
|
|
|
*/
|
2016-07-19 19:16:24 +08:00
|
|
|
rs->md.bitmap_info.chunksize = to_bytes(region_size);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-10-11 10:40:09 +08:00
|
|
|
/*
|
2013-01-23 11:42:18 +08:00
|
|
|
* validate_raid_redundancy
|
2012-10-11 10:40:09 +08:00
|
|
|
* @rs
|
|
|
|
*
|
2013-01-23 11:42:18 +08:00
|
|
|
* Determine if there are enough devices in the array that haven't
|
|
|
|
* failed (or are being rebuilt) to form a usable array.
|
2012-10-11 10:40:09 +08:00
|
|
|
*
|
|
|
|
* Returns: 0 on success, -EINVAL on failure.
|
|
|
|
*/
|
2013-01-23 11:42:18 +08:00
|
|
|
static int validate_raid_redundancy(struct raid_set *rs)
|
2012-10-11 10:40:09 +08:00
|
|
|
{
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int i, rebuild_cnt = 0;
|
2022-06-28 06:37:22 +08:00
|
|
|
unsigned int rebuilds_per_group = 0, copies, raid_disks;
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int group_size, last_group_start;
|
2012-10-11 10:40:09 +08:00
|
|
|
|
2022-06-28 06:37:22 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
|
|
|
if (!test_bit(FirstUse, &rs->dev[i].rdev.flags) &&
|
|
|
|
((!test_bit(In_sync, &rs->dev[i].rdev.flags) ||
|
|
|
|
!rs->dev[i].rdev.sb_page)))
|
2012-10-11 10:40:09 +08:00
|
|
|
rebuild_cnt++;
|
|
|
|
|
2017-12-14 00:13:17 +08:00
|
|
|
switch (rs->md.level) {
|
2016-08-17 21:36:44 +08:00
|
|
|
case 0:
|
|
|
|
break;
|
2012-10-11 10:40:09 +08:00
|
|
|
case 1:
|
|
|
|
if (rebuild_cnt >= rs->md.raid_disks)
|
|
|
|
goto too_many;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
case 5:
|
|
|
|
case 6:
|
|
|
|
if (rebuild_cnt > rs->raid_type->parity_devs)
|
|
|
|
goto too_many;
|
|
|
|
break;
|
|
|
|
case 10:
|
2016-06-13 23:55:14 +08:00
|
|
|
copies = raid10_md_layout_to_copies(rs->md.new_layout);
|
2017-12-14 00:13:17 +08:00
|
|
|
if (copies < 2) {
|
|
|
|
DMERR("Bogus raid10 data copies < 2!");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-10-11 10:40:24 +08:00
|
|
|
if (rebuild_cnt < copies)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is possible to have a higher rebuild count for RAID10,
|
|
|
|
* as long as the failed devices occur in different mirror
|
|
|
|
* groups (i.e. different stripes).
|
|
|
|
*
|
|
|
|
* When checking "near" format, make sure no adjacent devices
|
|
|
|
* have failed beyond what can be handled. In addition to the
|
|
|
|
* simple case where the number of devices is a multiple of the
|
|
|
|
* number of copies, we must also handle cases where the number
|
|
|
|
* of devices is not a multiple of the number of copies.
|
2016-05-31 01:03:37 +08:00
|
|
|
* E.g. dev1 dev2 dev3 dev4 dev5
|
|
|
|
* A A B B C
|
|
|
|
* C D D E E
|
2012-10-11 10:40:24 +08:00
|
|
|
*/
|
2022-06-28 06:37:22 +08:00
|
|
|
raid_disks = min(rs->raid_disks, rs->md.raid_disks);
|
2016-06-13 23:55:14 +08:00
|
|
|
if (__is_raid10_near(rs->md.new_layout)) {
|
2022-06-28 06:37:22 +08:00
|
|
|
for (i = 0; i < raid_disks; i++) {
|
2013-02-21 10:28:10 +08:00
|
|
|
if (!(i % copies))
|
|
|
|
rebuilds_per_group = 0;
|
2016-06-13 23:55:14 +08:00
|
|
|
if ((!rs->dev[i].rdev.sb_page ||
|
2016-06-13 23:55:13 +08:00
|
|
|
!test_bit(In_sync, &rs->dev[i].rdev.flags)) &&
|
2013-02-21 10:28:10 +08:00
|
|
|
(++rebuilds_per_group >= copies))
|
|
|
|
goto too_many;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When checking "far" and "offset" formats, we need to ensure
|
|
|
|
* that the device that holds its copy is not also dead or
|
|
|
|
* being rebuilt. (Note that "far" and "offset" formats only
|
|
|
|
* support two copies right now. These formats also only ever
|
|
|
|
* use the 'use_far_sets' variant.)
|
|
|
|
*
|
|
|
|
* This check is somewhat complicated by the need to account
|
2016-05-31 01:03:37 +08:00
|
|
|
* for arrays that are not a multiple of (far) copies. This
|
2013-02-21 10:28:10 +08:00
|
|
|
* results in the need to treat the last (potentially larger)
|
|
|
|
* set differently.
|
|
|
|
*/
|
2022-06-28 06:37:22 +08:00
|
|
|
group_size = (raid_disks / copies);
|
|
|
|
last_group_start = (raid_disks / group_size) - 1;
|
2013-02-21 10:28:10 +08:00
|
|
|
last_group_start *= group_size;
|
2022-06-28 06:37:22 +08:00
|
|
|
for (i = 0; i < raid_disks; i++) {
|
2013-02-21 10:28:10 +08:00
|
|
|
if (!(i % copies) && !(i > last_group_start))
|
2013-01-23 11:42:18 +08:00
|
|
|
rebuilds_per_group = 0;
|
2013-02-21 10:28:10 +08:00
|
|
|
if ((!rs->dev[i].rdev.sb_page ||
|
|
|
|
!test_bit(In_sync, &rs->dev[i].rdev.flags)) &&
|
2012-10-11 10:40:24 +08:00
|
|
|
(++rebuilds_per_group >= copies))
|
2013-02-21 10:28:10 +08:00
|
|
|
goto too_many;
|
2012-10-11 10:40:24 +08:00
|
|
|
}
|
|
|
|
break;
|
2012-10-11 10:40:09 +08:00
|
|
|
default:
|
2013-01-23 11:42:18 +08:00
|
|
|
if (rebuild_cnt)
|
|
|
|
return -EINVAL;
|
2012-10-11 10:40:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
too_many:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/*
|
|
|
|
* Possible arguments are...
|
|
|
|
* <chunk_size> [optional_args]
|
|
|
|
*
|
2011-08-02 19:32:07 +08:00
|
|
|
* Argument definitions
|
|
|
|
* <chunk_size> The number of sectors per disk that
|
2016-05-31 01:03:37 +08:00
|
|
|
* will form the "stripe"
|
2011-08-02 19:32:07 +08:00
|
|
|
* [[no]sync] Force or prevent recovery of the
|
2016-05-31 01:03:37 +08:00
|
|
|
* entire array
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* [rebuild <idx>] Rebuild the drive indicated by the index
|
2011-08-02 19:32:07 +08:00
|
|
|
* [daemon_sleep <ms>] Time between bitmap daemon work to
|
2016-05-31 01:03:37 +08:00
|
|
|
* clear bits
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* [min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
|
|
|
* [max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
2011-08-02 19:32:07 +08:00
|
|
|
* [write_mostly <idx>] Indicate a write mostly drive via index
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* [max_write_behind <sectors>] See '-write-behind=' (man mdadm)
|
|
|
|
* [stripe_cache <sectors>] Stripe cache size for higher RAIDs
|
2016-05-31 01:03:37 +08:00
|
|
|
* [region_size <sectors>] Defines granularity of bitmap
|
2016-12-01 05:31:05 +08:00
|
|
|
* [journal_dev <dev>] raid4/5/6 journaling deviice
|
|
|
|
* (i.e. write hole closing log)
|
2012-08-01 10:44:26 +08:00
|
|
|
*
|
|
|
|
* RAID10-only options:
|
2016-05-31 01:03:37 +08:00
|
|
|
* [raid10_copies <# copies>] Number of copies. (Default: 2)
|
2013-02-21 10:28:10 +08:00
|
|
|
* [raid10_format <near|far|offset>] Layout algorithm. (Default: near)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-05-20 00:49:25 +08:00
|
|
|
static int parse_raid_params(struct raid_set *rs, struct dm_arg_set *as,
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int num_raid_params)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2016-06-13 23:55:14 +08:00
|
|
|
int value, raid10_format = ALGORITHM_RAID10_DEFAULT;
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int raid10_copies = 2;
|
|
|
|
unsigned int i, write_mostly = 0;
|
|
|
|
unsigned int region_size = 0;
|
2012-07-27 22:08:00 +08:00
|
|
|
sector_t max_io_len;
|
2016-05-20 00:49:25 +08:00
|
|
|
const char *arg, *key;
|
2016-05-20 00:49:26 +08:00
|
|
|
struct raid_dev *rd;
|
2016-05-20 00:49:30 +08:00
|
|
|
struct raid_type *rt = rs->raid_type;
|
2016-05-20 00:49:25 +08:00
|
|
|
|
|
|
|
arg = dm_shift_arg(as);
|
|
|
|
num_raid_params--; /* Account for chunk_size argument */
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
if (kstrtoint(arg, 10, &value) < 0) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Bad numerical argument given for chunk_size";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* First, parse the in-order required arguments
|
2011-08-02 19:32:07 +08:00
|
|
|
* "chunk_size" is the only argument of this type.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
if (rt_is_raid1(rt)) {
|
2011-08-02 19:32:07 +08:00
|
|
|
if (value)
|
|
|
|
DMERR("Ignoring chunk size parameter for RAID 1");
|
|
|
|
value = 0;
|
2016-06-01 02:26:52 +08:00
|
|
|
} else if (!is_power_of_2(value)) {
|
|
|
|
rs->ti->error = "Chunk size must be a power of 2";
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (value < 8) {
|
|
|
|
rs->ti->error = "Chunk size value is too small";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
rs->md.new_chunk_sectors = rs->md.chunk_sectors = value;
|
|
|
|
|
|
|
|
/*
|
2011-08-02 19:32:07 +08:00
|
|
|
* We set each individual device as In_sync with a completed
|
|
|
|
* 'recovery_offset'. If there has been a device failure or
|
|
|
|
* replacement then one of the following cases applies:
|
|
|
|
*
|
|
|
|
* 1) User specifies 'rebuild'.
|
2016-05-31 01:03:37 +08:00
|
|
|
* - Device is reset when param is read.
|
2011-08-02 19:32:07 +08:00
|
|
|
* 2) A new device is supplied.
|
2016-05-31 01:03:37 +08:00
|
|
|
* - No matching superblock found, resets device.
|
2011-08-02 19:32:07 +08:00
|
|
|
* 3) Device failure was transient and returns on reload.
|
2016-05-31 01:03:37 +08:00
|
|
|
* - Failure noticed, resets device for bitmap replay.
|
2011-08-02 19:32:07 +08:00
|
|
|
* 4) Device hadn't completed recovery after previous failure.
|
2016-05-31 01:03:37 +08:00
|
|
|
* - Superblock is read and overrides recovery_offset.
|
2011-08-02 19:32:07 +08:00
|
|
|
*
|
|
|
|
* What is found in the superblocks of the devices is always
|
|
|
|
* authoritative, unless 'rebuild' or '[no]sync' was specified.
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-06-30 20:37:50 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
set_bit(In_sync, &rs->dev[i].rdev.flags);
|
2011-08-02 19:32:07 +08:00
|
|
|
rs->dev[i].rdev.recovery_offset = MaxSector;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
/*
|
|
|
|
* Second, parse the unordered optional arguments
|
|
|
|
*/
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
for (i = 0; i < num_raid_params; i++) {
|
2016-05-20 00:49:31 +08:00
|
|
|
key = dm_shift_arg(as);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!key) {
|
|
|
|
rs->ti->error = "Not enough raid parameters given";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:25 +08:00
|
|
|
|
2016-06-02 23:58:51 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_NOSYNC))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one 'nosync' argument allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
continue;
|
|
|
|
}
|
2016-06-02 23:58:51 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_SYNC))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_SYNC, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one 'sync' argument allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:31 +08:00
|
|
|
continue;
|
|
|
|
}
|
2016-06-02 23:58:51 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_RAID10_USE_NEAR_SETS))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_RAID10_USE_NEAR_SETS, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one 'raid10_use_new_sets' argument allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
arg = dm_shift_arg(as);
|
|
|
|
i++; /* Account for the argument pairs */
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!arg) {
|
|
|
|
rs->ti->error = "Wrong number of raid parameters given";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2012-08-01 10:44:26 +08:00
|
|
|
|
2016-05-20 00:49:26 +08:00
|
|
|
/*
|
|
|
|
* Parameters that take a string value are checked here.
|
|
|
|
*/
|
2016-12-01 05:31:05 +08:00
|
|
|
/* "raid10_format {near|offset|far} */
|
2016-06-02 23:58:51 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_RAID10_FORMAT))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_RAID10_FORMAT, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one 'raid10_format' argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!rt_is_raid10(rt)) {
|
|
|
|
rs->ti->error = "'raid10_format' is an invalid parameter for this RAID type";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
raid10_format = raid10_name_to_format(arg);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (raid10_format < 0) {
|
|
|
|
rs->ti->error = "Invalid 'raid10_format' value given";
|
|
|
|
return raid10_format;
|
|
|
|
}
|
2012-08-01 10:44:26 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-03-23 00:44:38 +08:00
|
|
|
/* "journal_dev <dev>" */
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_JOURNAL_DEV))) {
|
|
|
|
int r;
|
|
|
|
struct md_rdev *jdev;
|
|
|
|
|
|
|
|
if (test_and_set_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags)) {
|
|
|
|
rs->ti->error = "Only one raid4/5/6 set journaling device allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!rt_is_raid456(rt)) {
|
|
|
|
rs->ti->error = "'journal_dev' is an invalid parameter for this RAID type";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
r = dm_get_device(rs->ti, arg, dm_table_get_mode(rs->ti->table),
|
|
|
|
&rs->journal_dev.dev);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "raid4/5/6 journal device lookup failure";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
jdev = &rs->journal_dev.rdev;
|
|
|
|
md_rdev_init(jdev);
|
|
|
|
jdev->mddev = &rs->md;
|
|
|
|
jdev->bdev = rs->journal_dev.dev->bdev;
|
2021-10-18 18:11:05 +08:00
|
|
|
jdev->sectors = bdev_nr_sectors(jdev->bdev);
|
2016-12-01 05:31:05 +08:00
|
|
|
if (jdev->sectors < MIN_RAID456_JOURNAL_SPACE) {
|
|
|
|
rs->ti->error = "No space for raid4/5/6 journal";
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
2017-03-23 00:44:38 +08:00
|
|
|
rs->journal_dev.mode = R5C_JOURNAL_MODE_WRITE_THROUGH;
|
2016-12-01 05:31:05 +08:00
|
|
|
set_bit(Journal, &jdev->flags);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2017-03-23 00:44:38 +08:00
|
|
|
/* "journal_mode <mode>" ("journal_dev" mandatory!) */
|
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_JOURNAL_MODE))) {
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (!test_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags)) {
|
|
|
|
rs->ti->error = "raid4/5/6 'journal_mode' is invalid without 'journal_dev'";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (test_and_set_bit(__CTR_FLAG_JOURNAL_MODE, &rs->ctr_flags)) {
|
|
|
|
rs->ti->error = "Only one raid4/5/6 'journal_mode' argument allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
r = dm_raid_journal_mode_to_md(arg);
|
|
|
|
if (r < 0) {
|
|
|
|
rs->ti->error = "Invalid 'journal_mode' argument";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
rs->journal_dev.mode = r;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/*
|
|
|
|
* Parameters with number values from here on.
|
|
|
|
*/
|
2016-06-13 23:55:14 +08:00
|
|
|
if (kstrtoint(arg, 10, &value) < 0) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Bad numerical argument given in raid params";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-02 23:58:51 +08:00
|
|
|
if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_REBUILD))) {
|
2016-05-20 00:49:26 +08:00
|
|
|
/*
|
|
|
|
* "rebuild" is being passed in by userspace to provide
|
|
|
|
* indexes of replaced devices and to set up additional
|
|
|
|
* devices on raid level takeover.
|
2016-05-31 01:03:37 +08:00
|
|
|
*/
|
2016-06-03 00:06:54 +08:00
|
|
|
if (!__within_range(value, 0, rs->raid_disks - 1)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Invalid rebuild index given";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
if (test_and_set_bit(value, (void *) rs->rebuild_disks)) {
|
|
|
|
rs->ti->error = "rebuild for this index already given";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-05-20 00:49:26 +08:00
|
|
|
rd = rs->dev + value;
|
|
|
|
clear_bit(In_sync, &rd->rdev.flags);
|
|
|
|
clear_bit(Faulty, &rd->rdev.flags);
|
|
|
|
rd->rdev.recovery_offset = 0;
|
2016-06-03 00:27:46 +08:00
|
|
|
set_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags);
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_WRITE_MOSTLY))) {
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rt_is_raid1(rt)) {
|
|
|
|
rs->ti->error = "write_mostly option is only valid for RAID1";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-03 00:06:54 +08:00
|
|
|
if (!__within_range(value, 0, rs->md.raid_disks - 1)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Invalid write_mostly index given";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-06-16 00:50:18 +08:00
|
|
|
write_mostly++;
|
2011-08-02 19:32:07 +08:00
|
|
|
set_bit(WriteMostly, &rs->dev[value].rdev.flags);
|
2016-06-03 00:27:46 +08:00
|
|
|
set_bit(__CTR_FLAG_WRITE_MOSTLY, &rs->ctr_flags);
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_MAX_WRITE_BEHIND))) {
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rt_is_raid1(rt)) {
|
|
|
|
rs->ti->error = "max_write_behind option is only valid for RAID1";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_MAX_WRITE_BEHIND, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one max_write_behind argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In device-mapper, we specify things in sectors, but
|
|
|
|
* MD records this value in kB
|
|
|
|
*/
|
2018-03-28 23:07:14 +08:00
|
|
|
if (value < 0 || value / 2 > COUNTER_MAX) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Max write-behind limit out of range";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2018-03-28 23:07:14 +08:00
|
|
|
rs->md.bitmap_info.max_write_behind = value / 2;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_DAEMON_SLEEP))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_DAEMON_SLEEP, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one daemon_sleep argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-28 23:07:14 +08:00
|
|
|
if (value < 0) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "daemon sleep period out of range";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->md.bitmap_info.daemon_sleep = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_DATA_OFFSET))) {
|
2022-06-21 19:32:34 +08:00
|
|
|
/* Userspace passes new data_offset after having extended the data image LV */
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_DATA_OFFSET, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one data_offset argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:31 +08:00
|
|
|
/* Ensure sensible data offset */
|
2016-06-16 04:27:08 +08:00
|
|
|
if (value < 0 ||
|
|
|
|
(value && (value < MIN_FREE_RESHAPE_SPACE || value % to_sector(PAGE_SIZE)))) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Bogus data_offset value";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:31 +08:00
|
|
|
rs->data_offset = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_DELTA_DISKS))) {
|
2016-05-20 00:49:31 +08:00
|
|
|
/* Define the +/-# of disks to add to/remove from the given raid set */
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_DELTA_DISKS, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one delta_disks argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:31 +08:00
|
|
|
/* Ensure MAX_RAID_DEVICES and raid type minimal_devs! */
|
2016-06-03 00:06:54 +08:00
|
|
|
if (!__within_range(abs(value), 1, MAX_RAID_DEVICES - rt->minimal_devs)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Too many delta_disk requested";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:31 +08:00
|
|
|
|
|
|
|
rs->delta_disks = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_STRIPE_CACHE))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_STRIPE_CACHE, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one stripe_cache argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!rt_is_raid456(rt)) {
|
|
|
|
rs->ti->error = "Inappropriate argument: stripe_cache";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2018-03-28 23:07:14 +08:00
|
|
|
if (value < 0) {
|
|
|
|
rs->ti->error = "Bogus stripe cache entries value";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-06-13 23:55:14 +08:00
|
|
|
rs->stripe_cache_entries = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_MIN_RECOVERY_RATE))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_MIN_RECOVERY_RATE, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one min_recovery_rate argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-28 23:07:14 +08:00
|
|
|
|
|
|
|
if (value < 0) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "min_recovery_rate out of range";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-28 23:07:14 +08:00
|
|
|
rs->md.sync_speed_min = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_MAX_RECOVERY_RATE))) {
|
2016-07-28 05:34:01 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_MAX_RECOVERY_RATE, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one max_recovery_rate argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-28 23:07:14 +08:00
|
|
|
|
|
|
|
if (value < 0) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "max_recovery_rate out of range";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2018-03-28 23:07:14 +08:00
|
|
|
rs->md.sync_speed_max = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_REGION_SIZE))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_REGION_SIZE, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one region_size argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
region_size = value;
|
2016-06-14 07:46:03 +08:00
|
|
|
rs->requested_bitmap_chunk_sectors = value;
|
2016-06-02 23:58:51 +08:00
|
|
|
} else if (!strcasecmp(key, dm_raid_arg_name_by_flag(CTR_FLAG_RAID10_COPIES))) {
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(__CTR_FLAG_RAID10_COPIES, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Only one raid10_copies argument pair allowed";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-06-03 00:06:54 +08:00
|
|
|
if (!__within_range(value, 2, rs->md.raid_disks)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Bad value for 'raid10_copies'";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2012-08-01 10:44:26 +08:00
|
|
|
raid10_copies = value;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
} else {
|
|
|
|
DMERR("Unable to parse RAID parameter: %s", key);
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "Unable to parse RAID parameter";
|
|
|
|
return -EINVAL;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-16 00:43:55 +08:00
|
|
|
if (test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags) &&
|
|
|
|
test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags)) {
|
|
|
|
rs->ti->error = "sync and nosync are mutually exclusive";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-06-25 05:21:37 +08:00
|
|
|
if (test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags) &&
|
|
|
|
(test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags) ||
|
|
|
|
test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags))) {
|
|
|
|
rs->ti->error = "sync/nosync and rebuild are mutually exclusive";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-06-16 00:50:18 +08:00
|
|
|
if (write_mostly >= rs->md.raid_disks) {
|
|
|
|
rs->ti->error = "Can't set all raid1 devices to write_mostly";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2018-03-28 23:07:14 +08:00
|
|
|
if (rs->md.sync_speed_max &&
|
|
|
|
rs->md.sync_speed_min > rs->md.sync_speed_max) {
|
|
|
|
rs->ti->error = "Bogus recovery rates";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
if (validate_region_size(rs, region_size))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (rs->md.chunk_sectors)
|
2012-07-27 22:08:00 +08:00
|
|
|
max_io_len = rs->md.chunk_sectors;
|
2011-08-02 19:32:07 +08:00
|
|
|
else
|
2012-07-27 22:08:00 +08:00
|
|
|
max_io_len = region_size;
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2012-07-27 22:08:00 +08:00
|
|
|
if (dm_set_target_max_io_len(rs->ti, max_io_len))
|
|
|
|
return -EINVAL;
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
if (rt_is_raid10(rt)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
if (raid10_copies > rs->md.raid_disks) {
|
|
|
|
rs->ti->error = "Not enough devices to satisfy specification";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2012-08-01 10:44:26 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
rs->md.new_layout = raid10_format_to_md_layout(rs, raid10_format, raid10_copies);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (rs->md.new_layout < 0) {
|
|
|
|
rs->ti->error = "Error getting raid10 format";
|
|
|
|
return rs->md.new_layout;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
rt = get_raid_type_by_ll(10, rs->md.new_layout);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rt) {
|
|
|
|
rs->ti->error = "Failed to recognize new raid10 layout";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
if ((rt->algorithm == ALGORITHM_RAID10_DEFAULT ||
|
|
|
|
rt->algorithm == ALGORITHM_RAID10_NEAR) &&
|
2016-06-03 00:27:46 +08:00
|
|
|
test_bit(__CTR_FLAG_RAID10_USE_NEAR_SETS, &rs->ctr_flags)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "RAID10 format 'near' and 'raid10_use_near_sets' are incompatible";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
2016-05-20 00:49:26 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
rs->raid10_copies = raid10_copies;
|
2012-07-27 22:08:04 +08:00
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/* Assume there are no metadata devices until the drives are parsed */
|
|
|
|
rs->md.persistent = 0;
|
|
|
|
rs->md.external = 1;
|
|
|
|
|
2016-05-20 00:49:27 +08:00
|
|
|
/* Check, if any invalid ctr arguments have been passed in for the raid level */
|
2016-06-09 22:42:16 +08:00
|
|
|
return rs_check_for_valid_flags(rs);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/* Set raid4/5/6 cache size */
|
|
|
|
static int rs_set_raid456_stripe_cache(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
struct r5conf *conf;
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
uint32_t min_stripes = max(mddev->chunk_sectors, mddev->new_chunk_sectors) / 2;
|
|
|
|
uint32_t nr_stripes = rs->stripe_cache_entries;
|
|
|
|
|
|
|
|
if (!rt_is_raid456(rs->raid_type)) {
|
|
|
|
rs->ti->error = "Inappropriate raid level; cannot change stripe_cache size";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (nr_stripes < min_stripes) {
|
|
|
|
DMINFO("Adjusting requested %u stripe cache entries to %u to suit stripe size",
|
|
|
|
nr_stripes, min_stripes);
|
|
|
|
nr_stripes = min_stripes;
|
|
|
|
}
|
|
|
|
|
|
|
|
conf = mddev->private;
|
|
|
|
if (!conf) {
|
|
|
|
rs->ti->error = "Cannot change stripe_cache size on inactive RAID set";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Try setting number of stripes in raid456 stripe cache */
|
|
|
|
if (conf->min_nr_stripes != nr_stripes) {
|
|
|
|
r = raid5_set_cache_size(mddev, nr_stripes);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "Failed to set raid4/5/6 stripe cache size";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
DMINFO("%u stripe cache entries", nr_stripes);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:34 +08:00
|
|
|
/* Return # of data stripes as kept in mddev as of @rs (i.e. as of superblock) */
|
|
|
|
static unsigned int mddev_data_stripes(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.raid_disks - rs->raid_type->parity_devs;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/* Return # of data stripes of @rs (i.e. as of ctr) */
|
|
|
|
static unsigned int rs_data_stripes(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->raid_disks - rs->raid_type->parity_devs;
|
|
|
|
}
|
|
|
|
|
2017-01-14 10:53:08 +08:00
|
|
|
/*
|
|
|
|
* Retrieve rdev->sectors from any valid raid device of @rs
|
|
|
|
* to allow userpace to pass in arbitray "- -" device tupples.
|
|
|
|
*/
|
|
|
|
static sector_t __rdev_sectors(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2022-06-28 06:37:22 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
2017-01-14 10:53:08 +08:00
|
|
|
struct md_rdev *rdev = &rs->dev[i].rdev;
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags) &&
|
|
|
|
rdev->bdev && rdev->sectors)
|
2017-01-14 10:53:08 +08:00
|
|
|
return rdev->sectors;
|
|
|
|
}
|
|
|
|
|
2017-06-30 21:45:58 +08:00
|
|
|
return 0;
|
2017-01-14 10:53:08 +08:00
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:59 +08:00
|
|
|
/* Check that calculated dev_sectors fits all component devices. */
|
|
|
|
static int _check_data_dev_sectors(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
sector_t ds = ~0;
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
|
|
|
|
rdev_for_each(rdev, &rs->md)
|
|
|
|
if (!test_bit(Journal, &rdev->flags) && rdev->bdev) {
|
2021-10-18 18:11:05 +08:00
|
|
|
ds = min(ds, bdev_nr_sectors(rdev->bdev));
|
2017-12-02 08:03:59 +08:00
|
|
|
if (ds < rs->md.dev_sectors) {
|
|
|
|
rs->ti->error = "Component device(s) too small";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/* Calculate the sectors per device and per array used for @rs */
|
2019-10-01 23:47:52 +08:00
|
|
|
static int rs_set_dev_and_array_sectors(struct raid_set *rs, sector_t sectors, bool use_mddev)
|
2016-06-13 23:55:13 +08:00
|
|
|
{
|
|
|
|
int delta_disks;
|
|
|
|
unsigned int data_stripes;
|
2019-10-01 23:47:52 +08:00
|
|
|
sector_t array_sectors = sectors, dev_sectors = sectors;
|
2016-06-13 23:55:13 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
if (use_mddev) {
|
|
|
|
delta_disks = mddev->delta_disks;
|
|
|
|
data_stripes = mddev_data_stripes(rs);
|
|
|
|
} else {
|
|
|
|
delta_disks = rs->delta_disks;
|
|
|
|
data_stripes = rs_data_stripes(rs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Special raid1 case w/o delta_disks support (yet) */
|
|
|
|
if (rt_is_raid1(rs->raid_type))
|
|
|
|
;
|
|
|
|
else if (rt_is_raid10(rs->raid_type)) {
|
|
|
|
if (rs->raid10_copies < 2 ||
|
|
|
|
delta_disks < 0) {
|
|
|
|
rs->ti->error = "Bogus raid10 data copies or delta disks";
|
2016-07-19 20:03:51 +08:00
|
|
|
return -EINVAL;
|
2016-06-13 23:55:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
dev_sectors *= rs->raid10_copies;
|
|
|
|
if (sector_div(dev_sectors, data_stripes))
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
array_sectors = (data_stripes + delta_disks) * dev_sectors;
|
|
|
|
if (sector_div(array_sectors, rs->raid10_copies))
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
} else if (sector_div(dev_sectors, data_stripes))
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
else
|
|
|
|
/* Striped layouts */
|
|
|
|
array_sectors = (data_stripes + delta_disks) * dev_sectors;
|
|
|
|
|
|
|
|
mddev->array_sectors = array_sectors;
|
|
|
|
mddev->dev_sectors = dev_sectors;
|
2019-10-01 23:47:52 +08:00
|
|
|
rs_set_rdev_sectors(rs);
|
2016-06-13 23:55:13 +08:00
|
|
|
|
2017-12-02 08:03:59 +08:00
|
|
|
return _check_data_dev_sectors(rs);
|
2016-06-13 23:55:13 +08:00
|
|
|
bad:
|
|
|
|
rs->ti->error = "Target length not divisible by number of data devices";
|
2016-07-19 20:03:51 +08:00
|
|
|
return -EINVAL;
|
2016-06-13 23:55:13 +08:00
|
|
|
}
|
|
|
|
|
2016-06-24 06:21:09 +08:00
|
|
|
/* Setup recovery on @rs */
|
2019-10-01 23:47:54 +08:00
|
|
|
static void rs_setup_recovery(struct raid_set *rs, sector_t dev_sectors)
|
2016-06-24 06:21:09 +08:00
|
|
|
{
|
|
|
|
/* raid0 does not recover */
|
|
|
|
if (rs_is_raid0(rs))
|
|
|
|
rs->md.recovery_cp = MaxSector;
|
|
|
|
/*
|
|
|
|
* A raid6 set has to be recovered either
|
|
|
|
* completely or for the grown part to
|
|
|
|
* ensure proper parity and Q-Syndrome
|
|
|
|
*/
|
|
|
|
else if (rs_is_raid6(rs))
|
|
|
|
rs->md.recovery_cp = dev_sectors;
|
|
|
|
/*
|
|
|
|
* Other raid set types may skip recovery
|
|
|
|
* depending on the 'nosync' flag.
|
|
|
|
*/
|
|
|
|
else
|
|
|
|
rs->md.recovery_cp = test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags)
|
|
|
|
? MaxSector : dev_sectors;
|
|
|
|
}
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
static void do_table_event(struct work_struct *ws)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = container_of(ws, struct raid_set, md.event_work);
|
|
|
|
|
2016-06-16 09:15:49 +08:00
|
|
|
smp_rmb(); /* Make sure we access most actual mddev properties */
|
2017-12-02 08:03:51 +08:00
|
|
|
if (!rs_is_reshaping(rs)) {
|
|
|
|
if (rs_is_raid10(rs))
|
|
|
|
rs_set_rdev_sectors(rs);
|
2016-06-16 09:15:49 +08:00
|
|
|
rs_set_capacity(rs);
|
2017-12-02 08:03:51 +08:00
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
dm_table_event(rs->ti->table);
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/*
|
|
|
|
* Make sure a valid takover (level switch) is being requested on @rs
|
|
|
|
*
|
|
|
|
* Conversions of raid sets from one MD personality to another
|
|
|
|
* have to conform to restrictions which are enforced here.
|
|
|
|
*/
|
|
|
|
static int rs_check_takeover(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
unsigned int near_copies;
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
if (rs->md.degraded) {
|
|
|
|
rs->ti->error = "Can't takeover degraded raid set";
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rs_is_reshaping(rs)) {
|
|
|
|
rs->ti->error = "Can't takeover reshaping raid set";
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
switch (mddev->level) {
|
|
|
|
case 0:
|
|
|
|
/* raid0 -> raid1/5 with one disk */
|
|
|
|
if ((mddev->new_level == 1 || mddev->new_level == 5) &&
|
|
|
|
mddev->raid_disks == 1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid0 -> raid10 */
|
|
|
|
if (mddev->new_level == 10 &&
|
2016-06-13 23:55:14 +08:00
|
|
|
!(rs->raid_disks % mddev->raid_disks))
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid0 with multiple disks -> raid4/5/6 */
|
2016-06-03 00:06:54 +08:00
|
|
|
if (__within_range(mddev->new_level, 4, 6) &&
|
2016-05-20 00:49:33 +08:00
|
|
|
mddev->new_layout == ALGORITHM_PARITY_N &&
|
|
|
|
mddev->raid_disks > 1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 10:
|
|
|
|
/* Can't takeover raid10_offset! */
|
2016-06-03 03:27:22 +08:00
|
|
|
if (__is_raid10_offset(mddev->layout))
|
2016-05-20 00:49:33 +08:00
|
|
|
break;
|
|
|
|
|
2016-06-03 03:27:22 +08:00
|
|
|
near_copies = __raid10_near_copies(mddev->layout);
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
/* raid10* -> raid0 */
|
|
|
|
if (mddev->new_level == 0) {
|
|
|
|
/* Can takeover raid10_near with raid disks divisable by data copies! */
|
|
|
|
if (near_copies > 1 &&
|
|
|
|
!(mddev->raid_disks % near_copies)) {
|
|
|
|
mddev->raid_disks /= near_copies;
|
|
|
|
mddev->delta_disks = mddev->raid_disks;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Can takeover raid10_far */
|
|
|
|
if (near_copies == 1 &&
|
2016-06-03 03:27:22 +08:00
|
|
|
__raid10_far_copies(mddev->layout) > 1)
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* raid10_{near,far} -> raid1 */
|
|
|
|
if (mddev->new_level == 1 &&
|
2016-06-03 03:27:22 +08:00
|
|
|
max(near_copies, __raid10_far_copies(mddev->layout)) == mddev->raid_disks)
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid10_{near,far} with 2 disks -> raid4/5 */
|
2016-06-03 00:06:54 +08:00
|
|
|
if (__within_range(mddev->new_level, 4, 5) &&
|
2016-05-20 00:49:33 +08:00
|
|
|
mddev->raid_disks == 2)
|
|
|
|
return 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 1:
|
|
|
|
/* raid1 with 2 disks -> raid4/5 */
|
2016-06-03 00:06:54 +08:00
|
|
|
if (__within_range(mddev->new_level, 4, 5) &&
|
2016-05-20 00:49:33 +08:00
|
|
|
mddev->raid_disks == 2) {
|
|
|
|
mddev->degraded = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* raid1 -> raid0 */
|
|
|
|
if (mddev->new_level == 0 &&
|
|
|
|
mddev->raid_disks == 1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid1 -> raid10 */
|
|
|
|
if (mddev->new_level == 10)
|
|
|
|
return 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 4:
|
|
|
|
/* raid4 -> raid0 */
|
|
|
|
if (mddev->new_level == 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid4 -> raid1/5 with 2 disks */
|
|
|
|
if ((mddev->new_level == 1 || mddev->new_level == 5) &&
|
|
|
|
mddev->raid_disks == 2)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid4 -> raid5/6 with parity N */
|
2016-06-03 00:06:54 +08:00
|
|
|
if (__within_range(mddev->new_level, 5, 6) &&
|
2016-05-20 00:49:33 +08:00
|
|
|
mddev->layout == ALGORITHM_PARITY_N)
|
|
|
|
return 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 5:
|
|
|
|
/* raid5 with parity N -> raid0 */
|
|
|
|
if (mddev->new_level == 0 &&
|
|
|
|
mddev->layout == ALGORITHM_PARITY_N)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid5 with parity N -> raid4 */
|
|
|
|
if (mddev->new_level == 4 &&
|
|
|
|
mddev->layout == ALGORITHM_PARITY_N)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid5 with 2 disks -> raid1/4/10 */
|
|
|
|
if ((mddev->new_level == 1 || mddev->new_level == 4 || mddev->new_level == 10) &&
|
|
|
|
mddev->raid_disks == 2)
|
|
|
|
return 0;
|
|
|
|
|
2016-06-16 04:29:09 +08:00
|
|
|
/* raid5_* -> raid6_*_6 with Q-Syndrome N (e.g. raid5_ra -> raid6_ra_6 */
|
2016-05-20 00:49:33 +08:00
|
|
|
if (mddev->new_level == 6 &&
|
|
|
|
((mddev->layout == ALGORITHM_PARITY_N && mddev->new_layout == ALGORITHM_PARITY_N) ||
|
2016-06-03 00:06:54 +08:00
|
|
|
__within_range(mddev->new_layout, ALGORITHM_LEFT_ASYMMETRIC_6, ALGORITHM_RIGHT_SYMMETRIC_6)))
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 6:
|
|
|
|
/* raid6 with parity N -> raid0 */
|
|
|
|
if (mddev->new_level == 0 &&
|
|
|
|
mddev->layout == ALGORITHM_PARITY_N)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* raid6 with parity N -> raid4 */
|
|
|
|
if (mddev->new_level == 4 &&
|
|
|
|
mddev->layout == ALGORITHM_PARITY_N)
|
|
|
|
return 0;
|
|
|
|
|
2016-06-16 04:29:09 +08:00
|
|
|
/* raid6_*_n with Q-Syndrome N -> raid5_* */
|
2016-05-20 00:49:33 +08:00
|
|
|
if (mddev->new_level == 5 &&
|
|
|
|
((mddev->layout == ALGORITHM_PARITY_N && mddev->new_layout == ALGORITHM_PARITY_N) ||
|
2016-06-03 00:06:54 +08:00
|
|
|
__within_range(mddev->new_layout, ALGORITHM_LEFT_ASYMMETRIC, ALGORITHM_RIGHT_SYMMETRIC)))
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
2021-04-21 06:09:02 +08:00
|
|
|
break;
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->ti->error = "takeover not possible";
|
|
|
|
return -EINVAL;
|
2016-05-20 00:49:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* True if @rs requested to be taken over */
|
|
|
|
static bool rs_takeover_requested(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
return rs->md.new_level != rs->md.level;
|
|
|
|
}
|
|
|
|
|
2021-04-22 05:32:36 +08:00
|
|
|
/* True if layout is set to reshape. */
|
|
|
|
static bool rs_is_layout_change(struct raid_set *rs, bool use_mddev)
|
|
|
|
{
|
|
|
|
return (use_mddev ? rs->md.delta_disks : rs->delta_disks) ||
|
|
|
|
rs->md.new_layout != rs->md.layout ||
|
|
|
|
rs->md.new_chunk_sectors != rs->md.chunk_sectors;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/* True if @rs is requested to reshape by ctr */
|
|
|
|
static bool rs_reshape_requested(struct raid_set *rs)
|
|
|
|
{
|
2016-06-30 00:13:58 +08:00
|
|
|
bool change;
|
2016-06-13 23:55:13 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
2016-06-30 00:13:58 +08:00
|
|
|
if (rs_takeover_requested(rs))
|
|
|
|
return false;
|
|
|
|
|
2017-12-14 00:13:21 +08:00
|
|
|
if (rs_is_raid0(rs))
|
2016-06-13 23:55:13 +08:00
|
|
|
return false;
|
|
|
|
|
2021-04-22 05:32:36 +08:00
|
|
|
change = rs_is_layout_change(rs, false);
|
2016-06-30 00:13:58 +08:00
|
|
|
|
|
|
|
/* Historical case to support raid1 reshape without delta disks */
|
2017-12-14 00:13:21 +08:00
|
|
|
if (rs_is_raid1(rs)) {
|
2016-06-30 19:57:08 +08:00
|
|
|
if (rs->delta_disks)
|
|
|
|
return !!rs->delta_disks;
|
|
|
|
|
2016-06-30 00:13:58 +08:00
|
|
|
return !change &&
|
|
|
|
mddev->raid_disks != rs->raid_disks;
|
2016-06-30 19:57:08 +08:00
|
|
|
}
|
2016-06-30 00:13:58 +08:00
|
|
|
|
2017-12-14 00:13:21 +08:00
|
|
|
if (rs_is_raid10(rs))
|
2016-06-30 00:13:58 +08:00
|
|
|
return change &&
|
|
|
|
!__is_raid10_far(mddev->new_layout) &&
|
|
|
|
rs->delta_disks >= 0;
|
|
|
|
|
|
|
|
return change;
|
2016-06-13 23:55:13 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Features */
|
2016-06-02 23:48:09 +08:00
|
|
|
#define FEATURE_FLAG_SUPPORTS_V190 0x1 /* Supports extended superblock */
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
/* State flags for sb->flags */
|
|
|
|
#define SB_FLAG_RESHAPE_ACTIVE 0x1
|
|
|
|
#define SB_FLAG_RESHAPE_BACKWARDS 0x2
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
/*
|
|
|
|
* This structure is never routinely used by userspace, unlike md superblocks.
|
|
|
|
* Devices with this superblock should only ever be accessed via device-mapper.
|
|
|
|
*/
|
|
|
|
#define DM_RAID_MAGIC 0x64526D44
|
|
|
|
struct dm_raid_superblock {
|
|
|
|
__le32 magic; /* "DmRd" */
|
2016-06-02 23:48:09 +08:00
|
|
|
__le32 compat_features; /* Used to indicate compatible features (like 1.9.0 ondisk metadata extension) */
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
__le32 num_devices; /* Number of devices in this raid set. (Max 64) */
|
|
|
|
__le32 array_position; /* The position of this drive in the raid set */
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
__le64 events; /* Incremented by md when superblock updated */
|
2016-06-02 23:48:09 +08:00
|
|
|
__le64 failed_devices; /* Pre 1.9.0 part of bit field of devices to */
|
2016-05-20 00:49:30 +08:00
|
|
|
/* indicate failures (see extension below) */
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This offset tracks the progress of the repair or replacement of
|
|
|
|
* an individual drive.
|
|
|
|
*/
|
|
|
|
__le64 disk_recovery_offset;
|
|
|
|
|
|
|
|
/*
|
2016-05-20 00:49:30 +08:00
|
|
|
* This offset tracks the progress of the initial raid set
|
2011-08-02 19:32:07 +08:00
|
|
|
* synchronisation/parity calculation.
|
|
|
|
*/
|
|
|
|
__le64 array_resync_offset;
|
|
|
|
|
|
|
|
/*
|
2016-05-20 00:49:30 +08:00
|
|
|
* raid characteristics
|
2011-08-02 19:32:07 +08:00
|
|
|
*/
|
|
|
|
__le32 level;
|
|
|
|
__le32 layout;
|
|
|
|
__le32 stripe_sectors;
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/********************************************************************
|
2016-06-02 23:48:09 +08:00
|
|
|
* BELOW FOLLOW V1.9.0 EXTENSIONS TO THE PRISTINE SUPERBLOCK FORMAT!!!
|
2016-05-20 00:49:30 +08:00
|
|
|
*
|
2017-06-23 23:27:01 +08:00
|
|
|
* FEATURE_FLAG_SUPPORTS_V190 in the compat_features member indicates that those exist
|
2016-05-20 00:49:30 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
__le32 flags; /* Flags defining array states for reshaping */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This offset tracks the progress of a raid
|
|
|
|
* set reshape in order to be able to restart it
|
|
|
|
*/
|
|
|
|
__le64 reshape_position;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These define the properties of the array in case of an interrupted reshape
|
|
|
|
*/
|
|
|
|
__le32 new_level;
|
|
|
|
__le32 new_layout;
|
|
|
|
__le32 new_stripe_sectors;
|
|
|
|
__le32 delta_disks;
|
|
|
|
|
|
|
|
__le64 array_sectors; /* Array size in sectors */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sector offsets to data on devices (reshaping).
|
|
|
|
* Needed to support out of place reshaping, thus
|
|
|
|
* not writing over any stripes whilst converting
|
|
|
|
* them from old to new layout
|
|
|
|
*/
|
|
|
|
__le64 data_offset;
|
|
|
|
__le64 new_data_offset;
|
|
|
|
|
|
|
|
__le64 sectors; /* Used device size in sectors */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Additonal Bit field of devices indicating failures to support
|
2016-06-02 23:48:09 +08:00
|
|
|
* up to 256 devices with the 1.9.0 on-disk metadata format
|
2016-05-20 00:49:30 +08:00
|
|
|
*/
|
|
|
|
__le64 extended_failed_devices[DISKS_ARRAY_ELEMS - 1];
|
|
|
|
|
|
|
|
__le32 incompat_features; /* Used to indicate any incompatible features */
|
|
|
|
|
|
|
|
/* Always set rest up to logical block size to 0 when writing (see get_metadata_device() below). */
|
2011-08-02 19:32:07 +08:00
|
|
|
} __packed;
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/*
|
|
|
|
* Check for reshape constraints on raid set @rs:
|
|
|
|
*
|
|
|
|
* - reshape function non-existent
|
|
|
|
* - degraded set
|
|
|
|
* - ongoing recovery
|
|
|
|
* - ongoing reshape
|
|
|
|
*
|
|
|
|
* Returns 0 if none or -EPERM if given constraint
|
|
|
|
* and error message reference in @errmsg
|
|
|
|
*/
|
|
|
|
static int rs_check_reshape(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
if (!mddev->pers || !mddev->pers->check_reshape)
|
|
|
|
rs->ti->error = "Reshape not supported";
|
|
|
|
else if (mddev->degraded)
|
|
|
|
rs->ti->error = "Can't reshape degraded raid set";
|
|
|
|
else if (rs_is_recovering(rs))
|
|
|
|
rs->ti->error = "Convert request on recovering raid set prohibited";
|
2016-06-30 00:13:58 +08:00
|
|
|
else if (rs_is_reshaping(rs))
|
2016-06-13 23:55:14 +08:00
|
|
|
rs->ti->error = "raid set already reshaping!";
|
2016-06-30 19:57:08 +08:00
|
|
|
else if (!(rs_is_raid1(rs) || rs_is_raid10(rs) || rs_is_raid456(rs)))
|
|
|
|
rs->ti->error = "Reshaping only supported for raid1/4/5/6/10";
|
2016-06-13 23:55:14 +08:00
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
2017-01-14 10:53:10 +08:00
|
|
|
static int read_disk_sb(struct md_rdev *rdev, int size, bool force_reload)
|
2011-08-02 19:32:07 +08:00
|
|
|
{
|
|
|
|
BUG_ON(!rdev->sb_page);
|
|
|
|
|
2017-01-14 10:53:10 +08:00
|
|
|
if (rdev->sb_loaded && !force_reload)
|
2011-08-02 19:32:07 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-01-14 10:53:10 +08:00
|
|
|
rdev->sb_loaded = 0;
|
|
|
|
|
2022-07-15 02:06:57 +08:00
|
|
|
if (!sync_page_io(rdev, 0, size, rdev->sb_page, REQ_OP_READ, true)) {
|
2012-03-29 01:41:26 +08:00
|
|
|
DMERR("Failed to read superblock of device at position %d",
|
|
|
|
rdev->raid_disk);
|
2012-05-22 11:55:31 +08:00
|
|
|
md_error(rdev->mddev, rdev);
|
2017-01-14 10:53:10 +08:00
|
|
|
set_bit(Faulty, &rdev->flags);
|
|
|
|
return -EIO;
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
rdev->sb_loaded = 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
static void sb_retrieve_failed_devices(struct dm_raid_superblock *sb, uint64_t *failed_devices)
|
|
|
|
{
|
|
|
|
failed_devices[0] = le64_to_cpu(sb->failed_devices);
|
|
|
|
memset(failed_devices + 1, 0, sizeof(sb->extended_failed_devices));
|
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
if (le32_to_cpu(sb->compat_features) & FEATURE_FLAG_SUPPORTS_V190) {
|
2016-05-20 00:49:30 +08:00
|
|
|
int i = ARRAY_SIZE(sb->extended_failed_devices);
|
|
|
|
|
|
|
|
while (i--)
|
|
|
|
failed_devices[i+1] = le64_to_cpu(sb->extended_failed_devices[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:32 +08:00
|
|
|
static void sb_update_failed_devices(struct dm_raid_superblock *sb, uint64_t *failed_devices)
|
|
|
|
{
|
|
|
|
int i = ARRAY_SIZE(sb->extended_failed_devices);
|
|
|
|
|
|
|
|
sb->failed_devices = cpu_to_le64(failed_devices[0]);
|
|
|
|
while (i--)
|
|
|
|
sb->extended_failed_devices[i] = cpu_to_le64(failed_devices[i+1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Synchronize the superblock members with the raid set properties
|
|
|
|
*
|
|
|
|
* All superblock data is little endian.
|
|
|
|
*/
|
2011-10-11 13:47:53 +08:00
|
|
|
static void super_sync(struct mddev *mddev, struct md_rdev *rdev)
|
2011-08-02 19:32:07 +08:00
|
|
|
{
|
2016-05-20 00:49:32 +08:00
|
|
|
bool update_failed_devices = false;
|
|
|
|
unsigned int i;
|
|
|
|
uint64_t failed_devices[DISKS_ARRAY_ELEMS];
|
2011-08-02 19:32:07 +08:00
|
|
|
struct dm_raid_superblock *sb;
|
2012-05-22 11:55:30 +08:00
|
|
|
struct raid_set *rs = container_of(mddev, struct raid_set, md);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:32 +08:00
|
|
|
/* No metadata device, no superblock */
|
|
|
|
if (!rdev->meta_bdev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
BUG_ON(!rdev->sb_page);
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
sb = page_address(rdev->sb_page);
|
|
|
|
|
2016-05-20 00:49:32 +08:00
|
|
|
sb_retrieve_failed_devices(sb, failed_devices);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:32 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
|
|
|
if (!rs->dev[i].data_dev || test_bit(Faulty, &rs->dev[i].rdev.flags)) {
|
|
|
|
update_failed_devices = true;
|
|
|
|
set_bit(i, (void *) failed_devices);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (update_failed_devices)
|
|
|
|
sb_update_failed_devices(sb, failed_devices);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
sb->magic = cpu_to_le32(DM_RAID_MAGIC);
|
2016-06-02 23:48:09 +08:00
|
|
|
sb->compat_features = cpu_to_le32(FEATURE_FLAG_SUPPORTS_V190);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
sb->num_devices = cpu_to_le32(mddev->raid_disks);
|
|
|
|
sb->array_position = cpu_to_le32(rdev->raid_disk);
|
|
|
|
|
|
|
|
sb->events = cpu_to_le64(mddev->events);
|
|
|
|
|
|
|
|
sb->disk_recovery_offset = cpu_to_le64(rdev->recovery_offset);
|
|
|
|
sb->array_resync_offset = cpu_to_le64(mddev->recovery_cp);
|
|
|
|
|
|
|
|
sb->level = cpu_to_le32(mddev->level);
|
|
|
|
sb->layout = cpu_to_le32(mddev->layout);
|
|
|
|
sb->stripe_sectors = cpu_to_le32(mddev->chunk_sectors);
|
2016-05-20 00:49:32 +08:00
|
|
|
|
2017-06-23 23:27:01 +08:00
|
|
|
/********************************************************************
|
|
|
|
* BELOW FOLLOW V1.9.0 EXTENSIONS TO THE PRISTINE SUPERBLOCK FORMAT!!!
|
|
|
|
*
|
|
|
|
* FEATURE_FLAG_SUPPORTS_V190 in the compat_features member indicates that those exist
|
|
|
|
*/
|
2016-05-20 00:49:32 +08:00
|
|
|
sb->new_level = cpu_to_le32(mddev->new_level);
|
|
|
|
sb->new_layout = cpu_to_le32(mddev->new_layout);
|
|
|
|
sb->new_stripe_sectors = cpu_to_le32(mddev->new_chunk_sectors);
|
|
|
|
|
|
|
|
sb->delta_disks = cpu_to_le32(mddev->delta_disks);
|
|
|
|
|
|
|
|
smp_rmb(); /* Make sure we access most recent reshape position */
|
|
|
|
sb->reshape_position = cpu_to_le64(mddev->reshape_position);
|
|
|
|
if (le64_to_cpu(sb->reshape_position) != MaxSector) {
|
|
|
|
/* Flag ongoing reshape */
|
|
|
|
sb->flags |= cpu_to_le32(SB_FLAG_RESHAPE_ACTIVE);
|
|
|
|
|
|
|
|
if (mddev->delta_disks < 0 || mddev->reshape_backwards)
|
|
|
|
sb->flags |= cpu_to_le32(SB_FLAG_RESHAPE_BACKWARDS);
|
2016-06-03 00:27:46 +08:00
|
|
|
} else {
|
|
|
|
/* Clear reshape flags */
|
|
|
|
sb->flags &= ~(cpu_to_le32(SB_FLAG_RESHAPE_ACTIVE|SB_FLAG_RESHAPE_BACKWARDS));
|
|
|
|
}
|
2016-05-20 00:49:32 +08:00
|
|
|
|
|
|
|
sb->array_sectors = cpu_to_le64(mddev->array_sectors);
|
|
|
|
sb->data_offset = cpu_to_le64(rdev->data_offset);
|
|
|
|
sb->new_data_offset = cpu_to_le64(rdev->new_data_offset);
|
|
|
|
sb->sectors = cpu_to_le64(rdev->sectors);
|
2016-08-03 23:47:04 +08:00
|
|
|
sb->incompat_features = cpu_to_le32(0);
|
2016-05-20 00:49:32 +08:00
|
|
|
|
|
|
|
/* Zero out the rest of the payload after the size of the superblock */
|
|
|
|
memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* super_load
|
|
|
|
*
|
|
|
|
* This function creates a superblock if one is not found on the device
|
|
|
|
* and will decide which superblock to use if there's a choice.
|
|
|
|
*
|
|
|
|
* Return: 1 if use rdev, 0 if use refdev, -Exxx otherwise
|
|
|
|
*/
|
2011-10-11 13:45:26 +08:00
|
|
|
static int super_load(struct md_rdev *rdev, struct md_rdev *refdev)
|
2011-08-02 19:32:07 +08:00
|
|
|
{
|
2016-05-20 00:49:24 +08:00
|
|
|
int r;
|
2011-08-02 19:32:07 +08:00
|
|
|
struct dm_raid_superblock *sb;
|
|
|
|
struct dm_raid_superblock *refsb;
|
|
|
|
uint64_t events_sb, events_refsb;
|
|
|
|
|
2017-01-14 10:53:10 +08:00
|
|
|
r = read_disk_sb(rdev, rdev->sb_size, false);
|
2016-05-20 00:49:24 +08:00
|
|
|
if (r)
|
|
|
|
return r;
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
sb = page_address(rdev->sb_page);
|
2012-03-08 03:09:47 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Two cases that we want to write new superblocks and rebuild:
|
|
|
|
* 1) New device (no matching magic number)
|
|
|
|
* 2) Device specified for rebuild (!In_sync w/ offset == 0)
|
|
|
|
*/
|
|
|
|
if ((sb->magic != cpu_to_le32(DM_RAID_MAGIC)) ||
|
|
|
|
(!test_bit(In_sync, &rdev->flags) && !rdev->recovery_offset)) {
|
2011-08-02 19:32:07 +08:00
|
|
|
super_sync(rdev->mddev, rdev);
|
|
|
|
|
|
|
|
set_bit(FirstUse, &rdev->flags);
|
2016-06-02 23:48:09 +08:00
|
|
|
sb->compat_features = cpu_to_le32(FEATURE_FLAG_SUPPORTS_V190);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
/* Force writing of superblocks to disk */
|
2016-12-09 07:48:19 +08:00
|
|
|
set_bit(MD_SB_CHANGE_DEVS, &rdev->mddev->sb_flags);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
/* Any superblock is better than none, choose that if given */
|
|
|
|
return refdev ? 0 : 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!refdev)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
events_sb = le64_to_cpu(sb->events);
|
|
|
|
|
|
|
|
refsb = page_address(refdev->sb_page);
|
|
|
|
events_refsb = le64_to_cpu(refsb->events);
|
|
|
|
|
|
|
|
return (events_sb > events_refsb) ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
static int super_init_validation(struct raid_set *rs, struct md_rdev *rdev)
|
2011-08-02 19:32:07 +08:00
|
|
|
{
|
|
|
|
int role;
|
2016-05-20 00:49:30 +08:00
|
|
|
unsigned int d;
|
|
|
|
struct mddev *mddev = &rs->md;
|
2011-08-02 19:32:07 +08:00
|
|
|
uint64_t events_sb;
|
2016-05-20 00:49:30 +08:00
|
|
|
uint64_t failed_devices[DISKS_ARRAY_ELEMS];
|
2011-08-02 19:32:07 +08:00
|
|
|
struct dm_raid_superblock *sb;
|
2016-05-20 00:49:30 +08:00
|
|
|
uint32_t new_devs = 0, rebuild_and_new = 0, rebuilds = 0;
|
2012-03-19 09:46:39 +08:00
|
|
|
struct md_rdev *r;
|
2011-08-02 19:32:07 +08:00
|
|
|
struct dm_raid_superblock *sb2;
|
|
|
|
|
|
|
|
sb = page_address(rdev->sb_page);
|
|
|
|
events_sb = le64_to_cpu(sb->events);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialise to 1 if this is a new superblock.
|
|
|
|
*/
|
|
|
|
mddev->events = events_sb ? : 1;
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
mddev->reshape_position = MaxSector;
|
|
|
|
|
2016-10-18 23:46:45 +08:00
|
|
|
mddev->raid_disks = le32_to_cpu(sb->num_devices);
|
|
|
|
mddev->level = le32_to_cpu(sb->level);
|
|
|
|
mddev->layout = le32_to_cpu(sb->layout);
|
|
|
|
mddev->chunk_sectors = le32_to_cpu(sb->stripe_sectors);
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
/*
|
2016-05-20 00:49:30 +08:00
|
|
|
* Reshaping is supported, e.g. reshape_position is valid
|
|
|
|
* in superblock and superblock content is authoritative.
|
2011-08-02 19:32:07 +08:00
|
|
|
*/
|
2016-06-03 00:27:46 +08:00
|
|
|
if (le32_to_cpu(sb->compat_features) & FEATURE_FLAG_SUPPORTS_V190) {
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Superblock is authoritative wrt given raid set layout! */
|
|
|
|
mddev->new_level = le32_to_cpu(sb->new_level);
|
|
|
|
mddev->new_layout = le32_to_cpu(sb->new_layout);
|
|
|
|
mddev->new_chunk_sectors = le32_to_cpu(sb->new_stripe_sectors);
|
|
|
|
mddev->delta_disks = le32_to_cpu(sb->delta_disks);
|
|
|
|
mddev->array_sectors = le64_to_cpu(sb->array_sectors);
|
|
|
|
|
|
|
|
/* raid was reshaping and got interrupted */
|
2016-06-03 00:27:46 +08:00
|
|
|
if (le32_to_cpu(sb->flags) & SB_FLAG_RESHAPE_ACTIVE) {
|
|
|
|
if (test_bit(__CTR_FLAG_DELTA_DISKS, &rs->ctr_flags)) {
|
2016-05-20 00:49:30 +08:00
|
|
|
DMERR("Reshape requested but raid set is still reshaping");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
if (mddev->delta_disks < 0 ||
|
2016-06-03 00:27:46 +08:00
|
|
|
(!mddev->delta_disks && (le32_to_cpu(sb->flags) & SB_FLAG_RESHAPE_BACKWARDS)))
|
2016-05-20 00:49:30 +08:00
|
|
|
mddev->reshape_backwards = 1;
|
|
|
|
else
|
|
|
|
mddev->reshape_backwards = 0;
|
|
|
|
|
|
|
|
mddev->reshape_position = le64_to_cpu(sb->reshape_position);
|
|
|
|
rs->raid_type = get_raid_type_by_ll(mddev->level, mddev->layout);
|
|
|
|
}
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/*
|
2016-06-02 23:48:09 +08:00
|
|
|
* No takeover/reshaping, because we don't have the extended v1.9.0 metadata
|
2016-05-20 00:49:30 +08:00
|
|
|
*/
|
2016-10-18 23:46:45 +08:00
|
|
|
struct raid_type *rt_cur = get_raid_type_by_ll(mddev->level, mddev->layout);
|
|
|
|
struct raid_type *rt_new = get_raid_type_by_ll(mddev->new_level, mddev->new_layout);
|
2016-05-20 00:49:30 +08:00
|
|
|
|
2016-10-18 23:46:45 +08:00
|
|
|
if (rs_takeover_requested(rs)) {
|
|
|
|
if (rt_cur && rt_new)
|
|
|
|
DMERR("Takeover raid sets from %s to %s not yet supported by metadata. (raid level change)",
|
|
|
|
rt_cur->name, rt_new->name);
|
|
|
|
else
|
|
|
|
DMERR("Takeover raid sets not yet supported by metadata. (raid level change)");
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (rs_reshape_requested(rs)) {
|
|
|
|
DMERR("Reshaping raid sets not yet supported by metadata. (raid layout change keeping level)");
|
|
|
|
if (mddev->layout != mddev->new_layout) {
|
|
|
|
if (rt_cur && rt_new)
|
|
|
|
DMERR(" current layout %s vs new layout %s",
|
|
|
|
rt_cur->name, rt_new->name);
|
|
|
|
else
|
|
|
|
DMERR(" current layout 0x%X vs new layout 0x%X",
|
|
|
|
le32_to_cpu(sb->layout), mddev->new_layout);
|
|
|
|
}
|
|
|
|
if (mddev->chunk_sectors != mddev->new_chunk_sectors)
|
|
|
|
DMERR(" current stripe sectors %u vs new stripe sectors %u",
|
|
|
|
mddev->chunk_sectors, mddev->new_chunk_sectors);
|
|
|
|
if (rs->delta_disks)
|
|
|
|
DMERR(" current %u disks vs new %u disks",
|
|
|
|
mddev->raid_disks, mddev->raid_disks + rs->delta_disks);
|
|
|
|
if (rs_is_raid10(rs)) {
|
|
|
|
DMERR(" Old layout: %s w/ %u copies",
|
|
|
|
raid10_md_layout_to_format(mddev->layout),
|
|
|
|
raid10_md_layout_to_copies(mddev->layout));
|
|
|
|
DMERR(" New layout: %s w/ %u copies",
|
|
|
|
raid10_md_layout_to_format(mddev->new_layout),
|
|
|
|
raid10_md_layout_to_copies(mddev->new_layout));
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-10-18 03:20:07 +08:00
|
|
|
DMINFO("Discovered old metadata format; upgrading to extended metadata format");
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
if (!test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags))
|
2011-08-02 19:32:07 +08:00
|
|
|
mddev->recovery_cp = le64_to_cpu(sb->array_resync_offset);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* During load, we set FirstUse if a new superblock was written.
|
|
|
|
* There are two reasons we might not have a superblock:
|
2016-05-20 00:49:30 +08:00
|
|
|
* 1) The raid set is brand new - in which case, all of the
|
2016-05-31 01:03:37 +08:00
|
|
|
* devices must have their In_sync bit set. Also,
|
2011-08-02 19:32:07 +08:00
|
|
|
* recovery_cp must be 0, unless forced.
|
2016-05-20 00:49:30 +08:00
|
|
|
* 2) This is a new device being added to an old raid set
|
2011-08-02 19:32:07 +08:00
|
|
|
* and the new device needs to be rebuilt - in which
|
|
|
|
* case the In_sync bit will /not/ be set and
|
|
|
|
* recovery_cp must be MaxSector.
|
2016-06-13 23:55:14 +08:00
|
|
|
* 3) This is/are a new device(s) being added to an old
|
|
|
|
* raid set during takeover to a higher raid level
|
|
|
|
* to provide capacity for redundancy or during reshape
|
|
|
|
* to add capacity to grow the raid set.
|
2011-08-02 19:32:07 +08:00
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
d = 0;
|
2012-03-19 09:46:39 +08:00
|
|
|
rdev_for_each(r, mddev) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (test_bit(Journal, &rdev->flags))
|
|
|
|
continue;
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
if (test_bit(FirstUse, &r->flags))
|
|
|
|
new_devs++;
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
if (!test_bit(In_sync, &r->flags)) {
|
2016-05-20 00:49:30 +08:00
|
|
|
DMINFO("Device %d specified for rebuild; clearing superblock",
|
|
|
|
r->raid_disk);
|
2011-08-02 19:32:07 +08:00
|
|
|
rebuilds++;
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
if (test_bit(FirstUse, &r->flags))
|
|
|
|
rebuild_and_new++;
|
|
|
|
}
|
|
|
|
|
|
|
|
d++;
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
if (new_devs == rs->raid_disks || !rebuilds) {
|
|
|
|
/* Replace a broken device */
|
|
|
|
if (new_devs == rs->raid_disks) {
|
|
|
|
DMINFO("Superblocks created for new raid set");
|
2011-08-02 19:32:07 +08:00
|
|
|
set_bit(MD_ARRAY_FIRST_USE, &mddev->flags);
|
2016-06-13 23:55:14 +08:00
|
|
|
} else if (new_devs != rebuilds &&
|
|
|
|
new_devs != rs->delta_disks) {
|
2016-05-20 00:49:30 +08:00
|
|
|
DMERR("New device injected into existing raid set without "
|
|
|
|
"'delta_disks' or 'rebuild' parameter specified");
|
2011-08-02 19:32:07 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
} else if (new_devs && new_devs != rebuilds) {
|
|
|
|
DMERR("%u 'rebuild' devices cannot be injected into"
|
|
|
|
" a raid set with %u other first-time devices",
|
|
|
|
rebuilds, new_devs);
|
2011-08-02 19:32:07 +08:00
|
|
|
return -EINVAL;
|
2016-05-20 00:49:30 +08:00
|
|
|
} else if (rebuilds) {
|
|
|
|
if (rebuild_and_new && rebuilds != rebuild_and_new) {
|
|
|
|
DMERR("new device%s provided without 'rebuild'",
|
|
|
|
new_devs > 1 ? "s" : "");
|
|
|
|
return -EINVAL;
|
2017-12-14 00:13:18 +08:00
|
|
|
} else if (!test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags) && rs_is_recovering(rs)) {
|
2016-05-20 00:49:30 +08:00
|
|
|
DMERR("'rebuild' specified while raid set is not in-sync (recovery_cp=%llu)",
|
|
|
|
(unsigned long long) mddev->recovery_cp);
|
|
|
|
return -EINVAL;
|
2016-06-13 23:55:14 +08:00
|
|
|
} else if (rs_is_reshaping(rs)) {
|
|
|
|
DMERR("'rebuild' specified while raid set is being reshaped (reshape_position=%llu)",
|
|
|
|
(unsigned long long) mddev->reshape_position);
|
2016-05-20 00:49:30 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now we set the Faulty bit for those devices that are
|
|
|
|
* recorded in the superblock as failed.
|
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
sb_retrieve_failed_devices(sb, failed_devices);
|
2012-03-19 09:46:39 +08:00
|
|
|
rdev_for_each(r, mddev) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (test_bit(Journal, &rdev->flags) ||
|
|
|
|
!r->sb_page)
|
2011-08-02 19:32:07 +08:00
|
|
|
continue;
|
|
|
|
sb2 = page_address(r->sb_page);
|
|
|
|
sb2->failed_devices = 0;
|
2016-05-20 00:49:30 +08:00
|
|
|
memset(sb2->extended_failed_devices, 0, sizeof(sb2->extended_failed_devices));
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check for any device re-ordering.
|
|
|
|
*/
|
|
|
|
if (!test_bit(FirstUse, &r->flags) && (r->raid_disk >= 0)) {
|
|
|
|
role = le32_to_cpu(sb2->array_position);
|
2016-05-20 00:49:30 +08:00
|
|
|
if (role < 0)
|
|
|
|
continue;
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
if (role != r->raid_disk) {
|
2016-10-18 23:46:45 +08:00
|
|
|
if (rs_is_raid10(rs) && __is_raid10_near(mddev->layout)) {
|
2016-06-03 03:27:22 +08:00
|
|
|
if (mddev->raid_disks % __raid10_near_copies(mddev->layout) ||
|
2016-06-01 02:26:52 +08:00
|
|
|
rs->raid_disks % rs->raid10_copies) {
|
|
|
|
rs->ti->error =
|
|
|
|
"Cannot change raid10 near set to odd # of devices!";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
|
|
|
|
sb2->array_position = cpu_to_le32(r->raid_disk);
|
|
|
|
|
|
|
|
} else if (!(rs_is_raid10(rs) && rt_is_raid0(rs->raid_type)) &&
|
2016-06-01 02:26:52 +08:00
|
|
|
!(rs_is_raid0(rs) && rt_is_raid10(rs->raid_type)) &&
|
|
|
|
!rt_is_raid1(rs->raid_type)) {
|
|
|
|
rs->ti->error = "Cannot change device positions in raid set";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2016-05-20 00:49:30 +08:00
|
|
|
|
2016-06-01 02:26:52 +08:00
|
|
|
DMINFO("raid device #%d now at position #%d", role, r->raid_disk);
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Partial recovery is performed on
|
|
|
|
* returning failed devices.
|
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
if (test_bit(role, (void *) failed_devices))
|
2011-08-02 19:32:07 +08:00
|
|
|
set_bit(Faulty, &r->flags);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-04-29 20:03:04 +08:00
|
|
|
static int super_validate(struct raid_set *rs, struct md_rdev *rdev)
|
2011-08-02 19:32:07 +08:00
|
|
|
{
|
2015-04-29 20:03:04 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
2016-05-20 00:49:30 +08:00
|
|
|
struct dm_raid_superblock *sb;
|
|
|
|
|
2017-01-14 10:53:07 +08:00
|
|
|
if (rs_is_raid0(rs) || !rdev->sb_page || rdev->raid_disk < 0)
|
2016-05-20 00:49:30 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
sb = page_address(rdev->sb_page);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If mddev->events is not set, we know we have not yet initialized
|
|
|
|
* the array.
|
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
if (!mddev->events && super_init_validation(rs, rdev))
|
2011-08-02 19:32:07 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-10-11 22:16:57 +08:00
|
|
|
if (le32_to_cpu(sb->compat_features) &&
|
|
|
|
le32_to_cpu(sb->compat_features) != FEATURE_FLAG_SUPPORTS_V190) {
|
2016-06-02 23:48:09 +08:00
|
|
|
rs->ti->error = "Unable to assemble array: Unknown flag(s) in compatible feature flags";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sb->incompat_features) {
|
2016-05-20 00:49:33 +08:00
|
|
|
rs->ti->error = "Unable to assemble array: No incompatible feature flags supported yet";
|
2016-04-30 00:59:56 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-10-01 23:47:54 +08:00
|
|
|
/* Enable bitmap creation on @rs unless no metadevs or raid0 or journaled raid4/5/6 set. */
|
2018-10-13 02:24:25 +08:00
|
|
|
mddev->bitmap_info.offset = (rt_is_raid0(rs->raid_type) || rs->journal_dev.dev) ? 0 : to_sector(4096);
|
2017-01-14 10:53:11 +08:00
|
|
|
mddev->bitmap_info.default_offset = mddev->bitmap_info.offset;
|
2015-04-29 20:03:04 +08:00
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
if (!test_and_clear_bit(FirstUse, &rdev->flags)) {
|
2017-06-23 23:27:01 +08:00
|
|
|
/*
|
|
|
|
* Retrieve rdev size stored in superblock to be prepared for shrink.
|
|
|
|
* Check extended superblock members are present otherwise the size
|
|
|
|
* will not be set!
|
|
|
|
*/
|
|
|
|
if (le32_to_cpu(sb->compat_features) & FEATURE_FLAG_SUPPORTS_V190)
|
|
|
|
rdev->sectors = le64_to_cpu(sb->sectors);
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
rdev->recovery_offset = le64_to_cpu(sb->disk_recovery_offset);
|
2016-05-20 00:49:30 +08:00
|
|
|
if (rdev->recovery_offset == MaxSector)
|
|
|
|
set_bit(In_sync, &rdev->flags);
|
|
|
|
/*
|
|
|
|
* If no reshape in progress -> we're recovering single
|
|
|
|
* disk(s) and have to set the device(s) to out-of-sync
|
|
|
|
*/
|
2016-06-13 23:55:14 +08:00
|
|
|
else if (!rs_is_reshaping(rs))
|
2016-05-20 00:49:30 +08:00
|
|
|
clear_bit(In_sync, &rdev->flags); /* Mandatory for recovery */
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If a device comes back, set it as not In_sync and no longer faulty.
|
|
|
|
*/
|
2016-05-20 00:49:30 +08:00
|
|
|
if (test_and_clear_bit(Faulty, &rdev->flags)) {
|
|
|
|
rdev->recovery_offset = 0;
|
2011-08-02 19:32:07 +08:00
|
|
|
clear_bit(In_sync, &rdev->flags);
|
|
|
|
rdev->saved_raid_disk = rdev->raid_disk;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:30 +08:00
|
|
|
/* Reshape support -> restore repective data offsets */
|
|
|
|
rdev->data_offset = le64_to_cpu(sb->data_offset);
|
|
|
|
rdev->new_data_offset = le64_to_cpu(sb->new_data_offset);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Analyse superblocks and select the freshest.
|
|
|
|
*/
|
|
|
|
static int analyse_superblocks(struct dm_target *ti, struct raid_set *rs)
|
|
|
|
{
|
2016-05-20 00:49:24 +08:00
|
|
|
int r;
|
2017-01-14 10:53:07 +08:00
|
|
|
struct md_rdev *rdev, *freshest;
|
2011-10-11 13:47:53 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
2011-08-02 19:32:07 +08:00
|
|
|
|
|
|
|
freshest = NULL;
|
2017-01-14 10:53:07 +08:00
|
|
|
rdev_for_each(rdev, mddev) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (test_bit(Journal, &rdev->flags))
|
|
|
|
continue;
|
|
|
|
|
2017-11-03 02:58:28 +08:00
|
|
|
if (!rdev->meta_bdev)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Set superblock offset/size for metadata device. */
|
|
|
|
rdev->sb_start = 0;
|
|
|
|
rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev);
|
|
|
|
if (rdev->sb_size < sizeof(struct dm_raid_superblock) || rdev->sb_size > PAGE_SIZE) {
|
|
|
|
DMERR("superblock size of a logical block is no longer valid");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-10-11 10:42:19 +08:00
|
|
|
/*
|
2015-04-29 20:03:00 +08:00
|
|
|
* Skipping super_load due to CTR_FLAG_SYNC will cause
|
2012-10-11 10:42:19 +08:00
|
|
|
* the array to undergo initialization again as
|
2016-05-31 01:03:37 +08:00
|
|
|
* though it were new. This is the intended effect
|
2012-10-11 10:42:19 +08:00
|
|
|
* of the "sync" directive.
|
|
|
|
*
|
2017-01-14 10:53:07 +08:00
|
|
|
* With reshaping capability added, we must ensure that
|
|
|
|
* that the "sync" directive is disallowed during the reshape.
|
2012-10-11 10:42:19 +08:00
|
|
|
*/
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags))
|
2012-10-11 10:42:19 +08:00
|
|
|
continue;
|
|
|
|
|
2016-05-20 00:49:24 +08:00
|
|
|
r = super_load(rdev, freshest);
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2016-05-20 00:49:24 +08:00
|
|
|
switch (r) {
|
2011-08-02 19:32:07 +08:00
|
|
|
case 1:
|
|
|
|
freshest = rdev;
|
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
break;
|
|
|
|
default:
|
2017-01-14 10:53:07 +08:00
|
|
|
/* This is a failure to read the superblock from the metadata device. */
|
2016-08-17 21:36:44 +08:00
|
|
|
/*
|
|
|
|
* We have to keep any raid0 data/metadata device pairs or
|
|
|
|
* the MD raid0 personality will fail to start the array.
|
|
|
|
*/
|
|
|
|
if (rs_is_raid0(rs))
|
|
|
|
continue;
|
|
|
|
|
2013-01-23 11:42:18 +08:00
|
|
|
/*
|
2017-01-14 10:53:07 +08:00
|
|
|
* We keep the dm_devs to be able to emit the device tuple
|
|
|
|
* properly on the table line in raid_status() (rather than
|
|
|
|
* mistakenly acting as if '- -' got passed into the constructor).
|
|
|
|
*
|
|
|
|
* The rdev has to stay on the same_set list to allow for
|
|
|
|
* the attempt to restore faulty devices on second resume.
|
2013-01-23 11:42:18 +08:00
|
|
|
*/
|
2017-01-14 10:53:07 +08:00
|
|
|
rdev->raid_disk = rdev->saved_raid_disk = -1;
|
|
|
|
break;
|
2011-08-02 19:32:07 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!freshest)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Validation of the freshest device provides the source of
|
|
|
|
* validation for the remaining devices.
|
|
|
|
*/
|
2016-06-13 23:55:14 +08:00
|
|
|
rs->ti->error = "Unable to assemble array: Invalid superblocks";
|
|
|
|
if (super_validate(rs, freshest))
|
2016-06-01 02:26:52 +08:00
|
|
|
return -EINVAL;
|
2011-08-02 19:32:07 +08:00
|
|
|
|
2017-07-13 23:36:12 +08:00
|
|
|
if (validate_raid_redundancy(rs)) {
|
|
|
|
rs->ti->error = "Insufficient redundancy to activate array";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-03-19 09:46:39 +08:00
|
|
|
rdev_for_each(rdev, mddev)
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags) &&
|
|
|
|
rdev != freshest &&
|
|
|
|
super_validate(rs, rdev))
|
2011-08-02 19:32:07 +08:00
|
|
|
return -EINVAL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/*
|
|
|
|
* Adjust data_offset and new_data_offset on all disk members of @rs
|
|
|
|
* for out of place reshaping if requested by contructor
|
|
|
|
*
|
|
|
|
* We need free space at the beginning of each raid disk for forward
|
|
|
|
* and at the end for backward reshapes which userspace has to provide
|
|
|
|
* via remapping/reordering of space.
|
|
|
|
*/
|
|
|
|
static int rs_adjust_data_offsets(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
sector_t data_offset = 0, new_data_offset = 0;
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
|
|
|
|
/* Constructor did not request data offset change */
|
|
|
|
if (!test_bit(__CTR_FLAG_DATA_OFFSET, &rs->ctr_flags)) {
|
|
|
|
if (!rs_is_reshapable(rs))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-09-07 02:02:54 +08:00
|
|
|
/* HM FIXME: get In_Sync raid_dev? */
|
2016-06-13 23:55:13 +08:00
|
|
|
rdev = &rs->dev[0].rdev;
|
|
|
|
|
|
|
|
if (rs->delta_disks < 0) {
|
|
|
|
/*
|
|
|
|
* Removing disks (reshaping backwards):
|
|
|
|
*
|
|
|
|
* - before reshape: data is at offset 0 and free space
|
|
|
|
* is at end of each component LV
|
|
|
|
*
|
|
|
|
* - after reshape: data is at offset rs->data_offset != 0 on each component LV
|
|
|
|
*/
|
|
|
|
data_offset = 0;
|
|
|
|
new_data_offset = rs->data_offset;
|
|
|
|
|
|
|
|
} else if (rs->delta_disks > 0) {
|
|
|
|
/*
|
|
|
|
* Adding disks (reshaping forwards):
|
|
|
|
*
|
|
|
|
* - before reshape: data is at offset rs->data_offset != 0 and
|
|
|
|
* free space is at begin of each component LV
|
|
|
|
*
|
|
|
|
* - after reshape: data is at offset 0 on each component LV
|
|
|
|
*/
|
|
|
|
data_offset = rs->data_offset;
|
|
|
|
new_data_offset = 0;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* User space passes in 0 for data offset after having removed reshape space
|
|
|
|
*
|
|
|
|
* - or - (data offset != 0)
|
|
|
|
*
|
|
|
|
* Changing RAID layout or chunk size -> toggle offsets
|
|
|
|
*
|
|
|
|
* - before reshape: data is at offset rs->data_offset 0 and
|
|
|
|
* free space is at end of each component LV
|
|
|
|
* -or-
|
|
|
|
* data is at offset rs->data_offset != 0 and
|
|
|
|
* free space is at begin of each component LV
|
|
|
|
*
|
2016-06-24 07:03:19 +08:00
|
|
|
* - after reshape: data is at offset 0 if it was at offset != 0
|
|
|
|
* or at offset != 0 if it was at offset 0
|
2016-06-13 23:55:13 +08:00
|
|
|
* on each component LV
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
data_offset = rs->data_offset ? rdev->data_offset : 0;
|
|
|
|
new_data_offset = data_offset ? 0 : rs->data_offset;
|
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we got a minimum amount of free sectors per device
|
|
|
|
*/
|
|
|
|
if (rs->data_offset &&
|
2021-10-18 18:11:05 +08:00
|
|
|
bdev_nr_sectors(rdev->bdev) - rs->md.dev_sectors < MIN_FREE_RESHAPE_SPACE) {
|
2016-06-13 23:55:13 +08:00
|
|
|
rs->ti->error = data_offset ? "No space for forward reshape" :
|
|
|
|
"No space for backward reshape";
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
out:
|
2017-12-02 08:03:49 +08:00
|
|
|
/*
|
|
|
|
* Raise recovery_cp in case data_offset != 0 to
|
|
|
|
* avoid false recovery positives in the constructor.
|
|
|
|
*/
|
|
|
|
if (rs->md.recovery_cp < rs->md.dev_sectors)
|
|
|
|
rs->md.recovery_cp += rs->dev[0].rdev.data_offset;
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/* Adjust data offsets on all rdevs but on any raid4/5/6 journal device */
|
2016-06-13 23:55:13 +08:00
|
|
|
rdev_for_each(rdev, &rs->md) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags)) {
|
|
|
|
rdev->data_offset = data_offset;
|
|
|
|
rdev->new_data_offset = new_data_offset;
|
|
|
|
}
|
2016-06-13 23:55:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/* Userpace reordered disks -> adjust raid_disk indexes in @rs */
|
2016-06-03 03:27:22 +08:00
|
|
|
static void __reorder_raid_disk_indexes(struct raid_set *rs)
|
2016-05-20 00:49:33 +08:00
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
|
|
|
|
rdev_for_each(rdev, &rs->md) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags)) {
|
|
|
|
rdev->raid_disk = i++;
|
|
|
|
rdev->saved_raid_disk = rdev->new_raid_disk = -1;
|
|
|
|
}
|
2016-05-20 00:49:33 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup @rs for takeover by a different raid level
|
|
|
|
*/
|
|
|
|
static int rs_setup_takeover(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
unsigned int d = mddev->raid_disks = rs->raid_disks;
|
|
|
|
sector_t new_data_offset = rs->dev[0].rdev.data_offset ? 0 : rs->data_offset;
|
|
|
|
|
|
|
|
if (rt_is_raid10(rs->raid_type)) {
|
2017-12-14 00:13:21 +08:00
|
|
|
if (rs_is_raid0(rs)) {
|
2016-05-20 00:49:33 +08:00
|
|
|
/* Userpace reordered disks -> adjust raid_disk indexes */
|
2016-06-03 03:27:22 +08:00
|
|
|
__reorder_raid_disk_indexes(rs);
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
/* raid0 -> raid10_far layout */
|
|
|
|
mddev->layout = raid10_format_to_md_layout(rs, ALGORITHM_RAID10_FAR,
|
|
|
|
rs->raid10_copies);
|
2017-12-14 00:13:21 +08:00
|
|
|
} else if (rs_is_raid1(rs))
|
2016-05-20 00:49:33 +08:00
|
|
|
/* raid1 -> raid10_near layout */
|
|
|
|
mddev->layout = raid10_format_to_md_layout(rs, ALGORITHM_RAID10_NEAR,
|
|
|
|
rs->raid_disks);
|
2016-07-19 20:03:51 +08:00
|
|
|
else
|
2016-05-20 00:49:33 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
clear_bit(MD_ARRAY_FIRST_USE, &mddev->flags);
|
|
|
|
mddev->recovery_cp = MaxSector;
|
|
|
|
|
|
|
|
while (d--) {
|
|
|
|
rdev = &rs->dev[d].rdev;
|
|
|
|
|
|
|
|
if (test_bit(d, (void *) rs->rebuild_disks)) {
|
|
|
|
clear_bit(In_sync, &rdev->flags);
|
|
|
|
clear_bit(Faulty, &rdev->flags);
|
|
|
|
mddev->recovery_cp = rdev->recovery_offset = 0;
|
|
|
|
/* Bitmap has to be created when we do an "up" takeover */
|
|
|
|
set_bit(MD_ARRAY_FIRST_USE, &mddev->flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
rdev->new_data_offset = new_data_offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-30 00:13:58 +08:00
|
|
|
/* Prepare @rs for reshape */
|
|
|
|
static int rs_prepare_reshape(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
bool reshape;
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
if (rs_is_raid10(rs)) {
|
|
|
|
if (rs->raid_disks != mddev->raid_disks &&
|
|
|
|
__is_raid10_near(mddev->layout) &&
|
|
|
|
rs->raid10_copies &&
|
|
|
|
rs->raid10_copies != __raid10_near_copies(mddev->layout)) {
|
|
|
|
/*
|
|
|
|
* raid disk have to be multiple of data copies to allow this conversion,
|
|
|
|
*
|
|
|
|
* This is actually not a reshape it is a
|
|
|
|
* rebuild of any additional mirrors per group
|
|
|
|
*/
|
|
|
|
if (rs->raid_disks % rs->raid10_copies) {
|
|
|
|
rs->ti->error = "Can't reshape raid10 mirror groups";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Userpace reordered disks to add/remove mirrors -> adjust raid_disk indexes */
|
|
|
|
__reorder_raid_disk_indexes(rs);
|
|
|
|
mddev->layout = raid10_format_to_md_layout(rs, ALGORITHM_RAID10_NEAR,
|
|
|
|
rs->raid10_copies);
|
|
|
|
mddev->new_layout = mddev->layout;
|
|
|
|
reshape = false;
|
|
|
|
} else
|
|
|
|
reshape = true;
|
|
|
|
|
|
|
|
} else if (rs_is_raid456(rs))
|
|
|
|
reshape = true;
|
|
|
|
|
|
|
|
else if (rs_is_raid1(rs)) {
|
2016-06-30 19:57:08 +08:00
|
|
|
if (rs->delta_disks) {
|
|
|
|
/* Process raid1 via delta_disks */
|
|
|
|
mddev->degraded = rs->delta_disks < 0 ? -rs->delta_disks : rs->delta_disks;
|
|
|
|
reshape = true;
|
|
|
|
} else {
|
|
|
|
/* Process raid1 without delta_disks */
|
|
|
|
mddev->raid_disks = rs->raid_disks;
|
|
|
|
reshape = false;
|
|
|
|
}
|
2016-06-30 00:13:58 +08:00
|
|
|
} else {
|
|
|
|
rs->ti->error = "Called with bogus raid type";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (reshape) {
|
|
|
|
set_bit(RT_FLAG_RESHAPE_RS, &rs->runtime_flags);
|
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
2016-06-30 19:57:08 +08:00
|
|
|
} else if (mddev->raid_disks < rs->raid_disks)
|
|
|
|
/* Create new superblocks and bitmaps, if any new disks */
|
2016-06-30 00:13:58 +08:00
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:49 +08:00
|
|
|
/* Get reshape sectors from data_offsets or raid set */
|
|
|
|
static sector_t _get_reshape_sectors(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
sector_t reshape_sectors = 0;
|
|
|
|
|
|
|
|
rdev_for_each(rdev, &rs->md)
|
|
|
|
if (!test_bit(Journal, &rdev->flags)) {
|
|
|
|
reshape_sectors = (rdev->data_offset > rdev->new_data_offset) ?
|
|
|
|
rdev->data_offset - rdev->new_data_offset :
|
|
|
|
rdev->new_data_offset - rdev->data_offset;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return max(reshape_sectors, (sector_t) rs->data_offset);
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/*
|
2021-04-22 05:32:36 +08:00
|
|
|
* Reshape:
|
2016-06-13 23:55:14 +08:00
|
|
|
* - change raid layout
|
|
|
|
* - change chunk size
|
|
|
|
* - add disks
|
|
|
|
* - remove disks
|
|
|
|
*/
|
|
|
|
static int rs_setup_reshape(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
int r = 0;
|
|
|
|
unsigned int cur_raid_devs, d;
|
2017-12-02 08:03:49 +08:00
|
|
|
sector_t reshape_sectors = _get_reshape_sectors(rs);
|
2016-06-13 23:55:14 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
struct md_rdev *rdev;
|
|
|
|
|
|
|
|
mddev->delta_disks = rs->delta_disks;
|
|
|
|
cur_raid_devs = mddev->raid_disks;
|
|
|
|
|
|
|
|
/* Ignore impossible layout change whilst adding/removing disks */
|
|
|
|
if (mddev->delta_disks &&
|
|
|
|
mddev->layout != mddev->new_layout) {
|
|
|
|
DMINFO("Ignoring invalid layout change with delta_disks=%d", rs->delta_disks);
|
|
|
|
mddev->new_layout = mddev->layout;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Adjust array size:
|
|
|
|
*
|
2017-12-02 08:03:49 +08:00
|
|
|
* - in case of adding disk(s), array size has
|
2016-06-13 23:55:14 +08:00
|
|
|
* to grow after the disk adding reshape,
|
|
|
|
* which'll hapen in the event handler;
|
|
|
|
* reshape will happen forward, so space has to
|
|
|
|
* be available at the beginning of each disk
|
|
|
|
*
|
2017-12-02 08:03:49 +08:00
|
|
|
* - in case of removing disk(s), array size
|
2016-06-13 23:55:14 +08:00
|
|
|
* has to shrink before starting the reshape,
|
|
|
|
* which'll happen here;
|
|
|
|
* reshape will happen backward, so space has to
|
|
|
|
* be available at the end of each disk
|
|
|
|
*
|
|
|
|
* - data_offset and new_data_offset are
|
2016-06-16 04:27:40 +08:00
|
|
|
* adjusted for aforementioned out of place
|
2016-06-13 23:55:14 +08:00
|
|
|
* reshaping based on userspace passing in
|
|
|
|
* the "data_offset <sectors>" key/value
|
2016-06-16 04:27:40 +08:00
|
|
|
* pair via the constructor
|
2016-06-13 23:55:14 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* Add disk(s) */
|
|
|
|
if (rs->delta_disks > 0) {
|
|
|
|
/* Prepare disks for check in raid4/5/6/10 {check|start}_reshape */
|
|
|
|
for (d = cur_raid_devs; d < rs->raid_disks; d++) {
|
|
|
|
rdev = &rs->dev[d].rdev;
|
|
|
|
clear_bit(In_sync, &rdev->flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* save_raid_disk needs to be -1, or recovery_offset will be set to 0
|
|
|
|
* by md, which'll store that erroneously in the superblock on reshape
|
|
|
|
*/
|
|
|
|
rdev->saved_raid_disk = -1;
|
|
|
|
rdev->raid_disk = d;
|
|
|
|
|
|
|
|
rdev->sectors = mddev->dev_sectors;
|
2016-06-30 19:57:08 +08:00
|
|
|
rdev->recovery_offset = rs_is_raid1(rs) ? 0 : MaxSector;
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:49 +08:00
|
|
|
mddev->reshape_backwards = 0; /* adding disk(s) -> forward reshape */
|
2016-06-13 23:55:14 +08:00
|
|
|
|
|
|
|
/* Remove disk(s) */
|
|
|
|
} else if (rs->delta_disks < 0) {
|
2019-10-01 23:47:52 +08:00
|
|
|
r = rs_set_dev_and_array_sectors(rs, rs->ti->len, true);
|
2016-06-13 23:55:14 +08:00
|
|
|
mddev->reshape_backwards = 1; /* removing disk(s) -> backward reshape */
|
|
|
|
|
|
|
|
/* Change layout and/or chunk size */
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Reshape layout (e.g. raid5_ls -> raid5_n) and/or chunk size:
|
|
|
|
*
|
|
|
|
* keeping number of disks and do layout change ->
|
|
|
|
*
|
|
|
|
* toggle reshape_backward depending on data_offset:
|
|
|
|
*
|
|
|
|
* - free space upfront -> reshape forward
|
|
|
|
*
|
|
|
|
* - free space at the end -> reshape backward
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* This utilizes free reshape space avoiding the need
|
|
|
|
* for userspace to move (parts of) LV segments in
|
|
|
|
* case of layout/chunksize change (for disk
|
|
|
|
* adding/removing reshape space has to be at
|
|
|
|
* the proper address (see above with delta_disks):
|
|
|
|
*
|
|
|
|
* add disk(s) -> begin
|
|
|
|
* remove disk(s)-> end
|
|
|
|
*/
|
|
|
|
mddev->reshape_backwards = rs->dev[0].rdev.data_offset ? 0 : 1;
|
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:49 +08:00
|
|
|
/*
|
|
|
|
* Adjust device size for forward reshape
|
|
|
|
* because md_finish_reshape() reduces it.
|
|
|
|
*/
|
|
|
|
if (!mddev->reshape_backwards)
|
|
|
|
rdev_for_each(rdev, &rs->md)
|
|
|
|
if (!test_bit(Journal, &rdev->flags))
|
|
|
|
rdev->sectors += reshape_sectors;
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2021-04-22 05:32:36 +08:00
|
|
|
/*
|
|
|
|
* If the md resync thread has updated superblock with max reshape position
|
|
|
|
* at the end of a reshape but not (yet) reset the layout configuration
|
|
|
|
* changes -> reset the latter.
|
|
|
|
*/
|
|
|
|
static void rs_reset_inconclusive_reshape(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
if (!rs_is_reshaping(rs) && rs_is_layout_change(rs, true)) {
|
|
|
|
rs_set_cur(rs);
|
|
|
|
rs->md.delta_disks = 0;
|
|
|
|
rs->md.reshape_backwards = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-24 23:47:18 +08:00
|
|
|
/*
|
2014-09-24 23:47:19 +08:00
|
|
|
* Enable/disable discard support on RAID set depending on
|
|
|
|
* RAID level and discard properties of underlying RAID members.
|
2014-09-24 23:47:18 +08:00
|
|
|
*/
|
2016-05-20 00:49:33 +08:00
|
|
|
static void configure_discard_support(struct raid_set *rs)
|
2014-09-24 23:47:18 +08:00
|
|
|
{
|
2014-09-24 23:47:19 +08:00
|
|
|
int i;
|
|
|
|
bool raid456;
|
2016-05-20 00:49:33 +08:00
|
|
|
struct dm_target *ti = rs->ti;
|
2014-09-24 23:47:19 +08:00
|
|
|
|
2017-04-06 01:21:23 +08:00
|
|
|
/*
|
|
|
|
* XXX: RAID level 4,5,6 require zeroing for safety.
|
|
|
|
*/
|
2017-12-14 00:13:21 +08:00
|
|
|
raid456 = rs_is_raid456(rs);
|
2014-09-24 23:47:18 +08:00
|
|
|
|
2016-06-30 20:37:50 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
2022-04-15 12:52:55 +08:00
|
|
|
if (!rs->dev[i].rdev.bdev ||
|
|
|
|
!bdev_max_discard_sectors(rs->dev[i].rdev.bdev))
|
2014-09-24 23:47:19 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (raid456) {
|
|
|
|
if (!devices_handle_discard_safely) {
|
|
|
|
DMERR("raid456 discard support disabled due to discard_zeroes_data uncertainty.");
|
|
|
|
DMERR("Set dm-raid.devices_handle_discard_safely=Y to override.");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-24 23:47:18 +08:00
|
|
|
ti->num_discard_bios = 1;
|
|
|
|
}
|
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
/*
|
2016-05-20 00:49:24 +08:00
|
|
|
* Construct a RAID0/1/10/4/5/6 mapping:
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* Args:
|
2016-05-31 01:03:37 +08:00
|
|
|
* <raid_type> <#raid_params> <raid_params>{0,} \
|
|
|
|
* <#raid_devs> [<meta_dev1> <dev1>]{1,}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*
|
2016-05-31 01:03:37 +08:00
|
|
|
* <raid_params> varies by <raid_type>. See 'parse_raid_params' for
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
* details on possible <raid_params>.
|
2016-05-20 00:49:24 +08:00
|
|
|
*
|
|
|
|
* Userspace is free to initialize the metadata devices, hence the superblocks to
|
|
|
|
* enforce recreation based on the passed in table parameters.
|
|
|
|
*
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
*/
|
2016-07-19 20:03:51 +08:00
|
|
|
static int raid_ctr(struct dm_target *ti, unsigned int argc, char **argv)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2016-05-20 00:49:24 +08:00
|
|
|
int r;
|
2017-12-02 08:03:50 +08:00
|
|
|
bool resize = false;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
struct raid_type *rt;
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int num_raid_params, num_raid_devs;
|
2019-10-01 23:47:53 +08:00
|
|
|
sector_t sb_array_sectors, rdev_sectors, reshape_sectors;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
struct raid_set *rs = NULL;
|
2016-05-20 00:49:25 +08:00
|
|
|
const char *arg;
|
2016-06-13 23:55:14 +08:00
|
|
|
struct rs_layout rs_layout;
|
2016-05-20 00:49:25 +08:00
|
|
|
struct dm_arg_set as = { argc, argv }, as_nrd;
|
|
|
|
struct dm_arg _args[] = {
|
|
|
|
{ 0, as.argc, "Cannot understand number of raid parameters" },
|
|
|
|
{ 1, 254, "Cannot understand number of raid devices parameters" }
|
|
|
|
};
|
|
|
|
|
|
|
|
arg = dm_shift_arg(&as);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!arg) {
|
|
|
|
ti->error = "No arguments";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
rt = get_raid_type(arg);
|
2016-06-01 02:26:52 +08:00
|
|
|
if (!rt) {
|
|
|
|
ti->error = "Unrecognised raid_type";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
/* Must have <#raid_params> */
|
|
|
|
if (dm_read_arg_group(_args, &as, &num_raid_params, &ti->error))
|
2016-05-31 01:03:37 +08:00
|
|
|
return -EINVAL;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
/* number of raid device tupples <meta_dev data_dev> */
|
|
|
|
as_nrd = as;
|
|
|
|
dm_consume_args(&as_nrd, num_raid_params);
|
|
|
|
_args[1].max = (as_nrd.argc - 1) / 2;
|
|
|
|
if (dm_read_arg(_args + 1, &as_nrd, &num_raid_devs, &ti->error))
|
2016-05-31 01:03:37 +08:00
|
|
|
return -EINVAL;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-06-03 00:06:54 +08:00
|
|
|
if (!__within_range(num_raid_devs, 1, MAX_RAID_DEVICES)) {
|
2016-06-01 02:26:52 +08:00
|
|
|
ti->error = "Invalid number of supplied raid devices";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2014-05-29 16:23:23 +08:00
|
|
|
|
2016-06-03 03:08:09 +08:00
|
|
|
rs = raid_set_alloc(ti, rt, num_raid_devs);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
if (IS_ERR(rs))
|
|
|
|
return PTR_ERR(rs);
|
|
|
|
|
2016-05-20 00:49:25 +08:00
|
|
|
r = parse_raid_params(rs, &as, num_raid_params);
|
2016-05-20 00:49:24 +08:00
|
|
|
if (r)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
goto bad;
|
|
|
|
|
2016-05-20 00:49:26 +08:00
|
|
|
r = parse_dev_params(rs, &as);
|
2016-05-20 00:49:24 +08:00
|
|
|
if (r)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
goto bad;
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
rs->md.sync_super = super_sync;
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-06-24 07:03:19 +08:00
|
|
|
/*
|
|
|
|
* Calculate ctr requested array and device sizes to allow
|
|
|
|
* for superblock analysis needing device sizes defined.
|
|
|
|
*
|
|
|
|
* Any existing superblock will overwrite the array and device sizes
|
|
|
|
*/
|
2019-10-01 23:47:52 +08:00
|
|
|
r = rs_set_dev_and_array_sectors(rs, rs->ti->len, false);
|
2016-06-13 23:55:13 +08:00
|
|
|
if (r)
|
2016-06-25 03:49:26 +08:00
|
|
|
goto bad;
|
2016-06-13 23:55:13 +08:00
|
|
|
|
2019-10-01 23:47:53 +08:00
|
|
|
/* Memorize just calculated, potentially larger sizes to grow the raid set in preresume */
|
|
|
|
rs->array_sectors = rs->md.array_sectors;
|
|
|
|
rs->dev_sectors = rs->md.dev_sectors;
|
2016-06-24 06:21:09 +08:00
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/*
|
|
|
|
* Backup any new raid set level, layout, ...
|
|
|
|
* requested to be able to compare to superblock
|
|
|
|
* members for conversion decisions.
|
|
|
|
*/
|
2016-06-13 23:55:14 +08:00
|
|
|
rs_config_backup(rs, &rs_layout);
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-05-20 00:49:24 +08:00
|
|
|
r = analyse_superblocks(ti, rs);
|
|
|
|
if (r)
|
2011-08-02 19:32:07 +08:00
|
|
|
goto bad;
|
|
|
|
|
2019-10-01 23:47:53 +08:00
|
|
|
/* All in-core metadata now as of current superblocks after calling analyse_superblocks() */
|
|
|
|
sb_array_sectors = rs->md.array_sectors;
|
2017-06-30 21:45:58 +08:00
|
|
|
rdev_sectors = __rdev_sectors(rs);
|
|
|
|
if (!rdev_sectors) {
|
|
|
|
ti->error = "Invalid rdev size";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:50 +08:00
|
|
|
|
|
|
|
reshape_sectors = _get_reshape_sectors(rs);
|
2019-10-01 23:47:53 +08:00
|
|
|
if (rs->dev_sectors != rdev_sectors) {
|
|
|
|
resize = (rs->dev_sectors != rdev_sectors - reshape_sectors);
|
|
|
|
if (rs->dev_sectors > rdev_sectors - reshape_sectors)
|
|
|
|
set_bit(RT_FLAG_RS_GROW, &rs->runtime_flags);
|
|
|
|
}
|
2016-06-24 06:21:09 +08:00
|
|
|
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
INIT_WORK(&rs->md.event_work, do_table_event);
|
|
|
|
ti->private = rs;
|
2013-03-02 06:45:47 +08:00
|
|
|
ti->num_flush_bios = 1;
|
2022-07-21 01:58:04 +08:00
|
|
|
ti->needs_bio_set_dev = true;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/* Restore any requested new layout for conversion decision */
|
2016-06-13 23:55:14 +08:00
|
|
|
rs_config_restore(rs, &rs_layout);
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-06-30 00:13:58 +08:00
|
|
|
/*
|
|
|
|
* Now that we have any superblock metadata available,
|
|
|
|
* check for new, recovering, reshaping, to be taken over,
|
|
|
|
* to be reshaped or an existing, unchanged raid set to
|
|
|
|
* run in sequence.
|
|
|
|
*/
|
2016-06-13 23:55:14 +08:00
|
|
|
if (test_bit(MD_ARRAY_FIRST_USE, &rs->md.flags)) {
|
2016-06-24 06:32:58 +08:00
|
|
|
/* A new raid6 set has to be recovered to ensure proper parity and Q-Syndrome */
|
|
|
|
if (rs_is_raid6(rs) &&
|
|
|
|
test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags)) {
|
|
|
|
ti->error = "'nosync' not allowed for new raid6 set";
|
2016-06-25 03:49:26 +08:00
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
2016-06-24 06:32:58 +08:00
|
|
|
}
|
|
|
|
rs_setup_recovery(rs, 0);
|
2016-06-27 20:44:09 +08:00
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
|
|
|
rs_set_new(rs);
|
|
|
|
} else if (rs_is_recovering(rs)) {
|
2016-06-30 00:13:58 +08:00
|
|
|
/* A recovering raid set may be resized */
|
2019-10-01 23:47:53 +08:00
|
|
|
goto size_check;
|
2016-06-27 20:44:09 +08:00
|
|
|
} else if (rs_is_reshaping(rs)) {
|
|
|
|
/* Have to reject size change request during reshape */
|
|
|
|
if (resize) {
|
|
|
|
ti->error = "Can't resize a reshaping raid set";
|
2016-06-25 03:49:26 +08:00
|
|
|
r = -EPERM;
|
|
|
|
goto bad;
|
2016-06-24 06:32:58 +08:00
|
|
|
}
|
2016-06-30 00:13:58 +08:00
|
|
|
/* skip setup rs */
|
2016-06-24 06:32:58 +08:00
|
|
|
} else if (rs_takeover_requested(rs)) {
|
2016-06-13 23:55:14 +08:00
|
|
|
if (rs_is_reshaping(rs)) {
|
|
|
|
ti->error = "Can't takeover a reshaping raid set";
|
2016-06-25 03:49:26 +08:00
|
|
|
r = -EPERM;
|
|
|
|
goto bad;
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/* We can't takeover a journaled raid4/5/6 */
|
|
|
|
if (test_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags)) {
|
|
|
|
ti->error = "Can't takeover a journaled raid4/5/6 set";
|
|
|
|
r = -EPERM;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/*
|
2016-06-24 07:03:19 +08:00
|
|
|
* If a takeover is needed, userspace sets any additional
|
2016-06-30 00:13:58 +08:00
|
|
|
* devices to rebuild and we can check for a valid request here.
|
|
|
|
*
|
|
|
|
* If acceptible, set the level to the new requested
|
2016-06-27 20:44:09 +08:00
|
|
|
* one, prohibit requesting recovery, allow the raid
|
|
|
|
* set to run and store superblocks during resume.
|
2016-06-13 23:55:14 +08:00
|
|
|
*/
|
2016-05-20 00:49:33 +08:00
|
|
|
r = rs_check_takeover(rs);
|
|
|
|
if (r)
|
2016-06-25 03:49:26 +08:00
|
|
|
goto bad;
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
r = rs_setup_takeover(rs);
|
|
|
|
if (r)
|
2016-06-25 03:49:26 +08:00
|
|
|
goto bad;
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
2016-06-30 00:13:58 +08:00
|
|
|
/* Takeover ain't recovery, so disable recovery */
|
2016-06-27 20:44:09 +08:00
|
|
|
rs_setup_recovery(rs, MaxSector);
|
2016-05-20 00:49:34 +08:00
|
|
|
rs_set_new(rs);
|
2016-06-13 23:55:13 +08:00
|
|
|
} else if (rs_reshape_requested(rs)) {
|
2019-10-01 23:47:54 +08:00
|
|
|
/* Only request grow on raid set size extensions, not on reshapes. */
|
2019-10-01 23:47:53 +08:00
|
|
|
clear_bit(RT_FLAG_RS_GROW, &rs->runtime_flags);
|
|
|
|
|
2016-12-01 05:31:05 +08:00
|
|
|
/*
|
|
|
|
* No need to check for 'ongoing' takeover here, because takeover
|
|
|
|
* is an instant operation as oposed to an ongoing reshape.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* We can't reshape a journaled raid4/5/6 */
|
|
|
|
if (test_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags)) {
|
|
|
|
ti->error = "Can't reshape a journaled raid4/5/6 set";
|
|
|
|
r = -EPERM;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2017-12-14 00:13:18 +08:00
|
|
|
/* Out-of-place space has to be available to allow for a reshape unless raid1! */
|
|
|
|
if (reshape_sectors || rs_is_raid1(rs)) {
|
|
|
|
/*
|
|
|
|
* We can only prepare for a reshape here, because the
|
|
|
|
* raid set needs to run to provide the repective reshape
|
|
|
|
* check functions via its MD personality instance.
|
|
|
|
*
|
|
|
|
* So do the reshape check after md_run() succeeded.
|
|
|
|
*/
|
|
|
|
r = rs_prepare_reshape(rs);
|
|
|
|
if (r)
|
2019-08-19 08:18:34 +08:00
|
|
|
goto bad;
|
2016-06-13 23:55:14 +08:00
|
|
|
|
2017-12-14 00:13:18 +08:00
|
|
|
/* Reshaping ain't recovery, so disable recovery */
|
|
|
|
rs_setup_recovery(rs, MaxSector);
|
|
|
|
}
|
2016-05-20 00:49:34 +08:00
|
|
|
rs_set_cur(rs);
|
2016-06-27 20:44:09 +08:00
|
|
|
} else {
|
2019-10-01 23:47:53 +08:00
|
|
|
size_check:
|
2016-06-27 20:44:09 +08:00
|
|
|
/* May not set recovery when a device rebuild is requested */
|
2016-06-25 05:21:37 +08:00
|
|
|
if (test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags)) {
|
2019-10-01 23:47:53 +08:00
|
|
|
clear_bit(RT_FLAG_RS_GROW, &rs->runtime_flags);
|
2016-06-25 05:21:37 +08:00
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
2019-10-01 23:47:54 +08:00
|
|
|
rs_setup_recovery(rs, MaxSector);
|
2019-10-01 23:47:53 +08:00
|
|
|
} else if (test_bit(RT_FLAG_RS_GROW, &rs->runtime_flags)) {
|
|
|
|
/*
|
2019-10-01 23:47:54 +08:00
|
|
|
* Set raid set to current size, i.e. size as of
|
|
|
|
* superblocks to grow to larger size in preresume.
|
2019-10-01 23:47:53 +08:00
|
|
|
*/
|
|
|
|
r = rs_set_dev_and_array_sectors(rs, sb_array_sectors, false);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
rs_setup_recovery(rs, rs->md.recovery_cp < rs->md.dev_sectors ? rs->md.recovery_cp : rs->md.dev_sectors);
|
|
|
|
} else {
|
|
|
|
/* This is no size change or it is shrinking, update size and record in superblocks */
|
|
|
|
r = rs_set_dev_and_array_sectors(rs, rs->ti->len, false);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
if (sb_array_sectors > rs->array_sectors)
|
|
|
|
set_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags);
|
|
|
|
}
|
2016-06-27 20:44:09 +08:00
|
|
|
rs_set_cur(rs);
|
2016-06-24 06:21:09 +08:00
|
|
|
}
|
2016-05-20 00:49:33 +08:00
|
|
|
|
2016-06-13 23:55:13 +08:00
|
|
|
/* If constructor requested it, change data and new_data offsets */
|
|
|
|
r = rs_adjust_data_offsets(rs);
|
|
|
|
if (r)
|
2016-06-25 03:49:26 +08:00
|
|
|
goto bad;
|
2016-06-13 23:55:13 +08:00
|
|
|
|
2021-04-22 05:32:36 +08:00
|
|
|
/* Catch any inconclusive reshape superblock content. */
|
|
|
|
rs_reset_inconclusive_reshape(rs);
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
/* Start raid set read-only and assumed clean to change in raid_resume() */
|
|
|
|
rs->md.ro = 1;
|
|
|
|
rs->md.in_sync = 1;
|
2018-09-07 02:02:54 +08:00
|
|
|
|
2021-04-22 05:32:36 +08:00
|
|
|
/* Keep array frozen until resume. */
|
2016-05-20 00:49:33 +08:00
|
|
|
set_bit(MD_RECOVERY_FROZEN, &rs->md.recovery);
|
2014-09-24 23:47:18 +08:00
|
|
|
|
2015-04-29 20:03:04 +08:00
|
|
|
/* Has to be held on running the array */
|
|
|
|
mddev_lock_nointr(&rs->md);
|
2016-05-20 00:49:24 +08:00
|
|
|
r = md_run(&rs->md);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
rs->md.in_sync = 0; /* Assume already marked dirty */
|
2016-05-20 00:49:24 +08:00
|
|
|
if (r) {
|
2016-06-13 23:55:14 +08:00
|
|
|
ti->error = "Failed to run raid array";
|
|
|
|
mddev_unlock(&rs->md);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2017-11-20 14:17:01 +08:00
|
|
|
r = md_start(&rs->md);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Failed to start raid array";
|
|
|
|
mddev_unlock(&rs->md);
|
|
|
|
goto bad_md_start;
|
|
|
|
}
|
|
|
|
|
2018-09-07 02:02:54 +08:00
|
|
|
/* If raid4/5/6 journal mode explicitly requested (only possible with journal dev) -> set it */
|
2017-03-23 00:44:38 +08:00
|
|
|
if (test_bit(__CTR_FLAG_JOURNAL_MODE, &rs->ctr_flags)) {
|
|
|
|
r = r5c_journal_mode_set(&rs->md, rs->journal_dev.mode);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Failed to set raid4/5/6 journal mode";
|
|
|
|
mddev_unlock(&rs->md);
|
|
|
|
goto bad_journal_mode_set;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-02 19:32:07 +08:00
|
|
|
mddev_suspend(&rs->md);
|
2017-07-13 23:34:24 +08:00
|
|
|
set_bit(RT_FLAG_RS_SUSPENDED, &rs->runtime_flags);
|
2016-06-13 23:55:14 +08:00
|
|
|
|
|
|
|
/* Try to adjust the raid4/5/6 stripe cache size to the stripe size */
|
|
|
|
if (rs_is_raid456(rs)) {
|
|
|
|
r = rs_set_raid456_stripe_cache(rs);
|
|
|
|
if (r)
|
|
|
|
goto bad_stripe_cache;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now do an early reshape check */
|
|
|
|
if (test_bit(RT_FLAG_RESHAPE_RS, &rs->runtime_flags)) {
|
|
|
|
r = rs_check_reshape(rs);
|
|
|
|
if (r)
|
2016-06-25 03:49:26 +08:00
|
|
|
goto bad_check_reshape;
|
2016-06-13 23:55:14 +08:00
|
|
|
|
|
|
|
/* Restore new, ctr requested layout to perform check */
|
|
|
|
rs_config_restore(rs, &rs_layout);
|
|
|
|
|
2016-06-30 19:57:08 +08:00
|
|
|
if (rs->md.pers->start_reshape) {
|
|
|
|
r = rs->md.pers->check_reshape(&rs->md);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Reshape check failed";
|
|
|
|
goto bad_check_reshape;
|
|
|
|
}
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-30 05:37:30 +08:00
|
|
|
/* Disable/enable discard support on raid set. */
|
|
|
|
configure_discard_support(rs);
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
mddev_unlock(&rs->md);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
return 0;
|
|
|
|
|
2017-11-20 14:17:01 +08:00
|
|
|
bad_md_start:
|
2017-03-23 00:44:38 +08:00
|
|
|
bad_journal_mode_set:
|
2016-06-13 23:55:14 +08:00
|
|
|
bad_stripe_cache:
|
|
|
|
bad_check_reshape:
|
2012-08-01 10:44:26 +08:00
|
|
|
md_stop(&rs->md);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
bad:
|
2016-06-03 03:08:09 +08:00
|
|
|
raid_set_free(rs);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:24 +08:00
|
|
|
return r;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void raid_dtr(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
|
|
|
|
|
|
|
md_stop(&rs->md);
|
2016-06-03 03:08:09 +08:00
|
|
|
raid_set_free(rs);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
2012-12-22 04:23:41 +08:00
|
|
|
static int raid_map(struct dm_target *ti, struct bio *bio)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
2011-10-11 13:47:53 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/*
|
|
|
|
* If we're reshaping to add disk(s)), ti->len and
|
|
|
|
* mddev->array_sectors will differ during the process
|
|
|
|
* (ti->len > mddev->array_sectors), so we have to requeue
|
|
|
|
* bios with addresses > mddev->array_sectors here or
|
2016-06-24 07:03:19 +08:00
|
|
|
* there will occur accesses past EOD of the component
|
2016-06-13 23:55:14 +08:00
|
|
|
* data images thus erroring the raid set.
|
|
|
|
*/
|
|
|
|
if (unlikely(bio_end_sector(bio) > mddev->array_sectors))
|
|
|
|
return DM_MAPIO_REQUEUE;
|
|
|
|
|
2017-09-22 01:29:22 +08:00
|
|
|
md_handle_request(mddev, bio);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
|
|
|
return DM_MAPIO_SUBMITTED;
|
|
|
|
}
|
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
/* Return sync state string for @state */
|
|
|
|
enum sync_state { st_frozen, st_reshape, st_resync, st_check, st_repair, st_recover, st_idle };
|
|
|
|
static const char *sync_str(enum sync_state state)
|
|
|
|
{
|
|
|
|
/* Has to be in above sync_state order! */
|
|
|
|
static const char *sync_strs[] = {
|
|
|
|
"frozen",
|
|
|
|
"reshape",
|
|
|
|
"resync",
|
|
|
|
"check",
|
|
|
|
"repair",
|
|
|
|
"recover",
|
|
|
|
"idle"
|
|
|
|
};
|
|
|
|
|
|
|
|
return __within_range(state, 0, ARRAY_SIZE(sync_strs) - 1) ? sync_strs[state] : "undef";
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Return enum sync_state for @mddev derived from @recovery flags */
|
2018-09-17 16:02:34 +08:00
|
|
|
static enum sync_state decipher_sync_action(struct mddev *mddev, unsigned long recovery)
|
2013-04-24 09:42:43 +08:00
|
|
|
{
|
2017-12-02 08:03:53 +08:00
|
|
|
if (test_bit(MD_RECOVERY_FROZEN, &recovery))
|
2018-09-07 04:54:29 +08:00
|
|
|
return st_frozen;
|
2013-04-24 09:42:43 +08:00
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
/* The MD sync thread can be done with io or be interrupted but still be running */
|
2017-12-02 08:03:55 +08:00
|
|
|
if (!test_bit(MD_RECOVERY_DONE, &recovery) &&
|
|
|
|
(test_bit(MD_RECOVERY_RUNNING, &recovery) ||
|
|
|
|
(!mddev->ro && test_bit(MD_RECOVERY_NEEDED, &recovery)))) {
|
2017-12-02 08:03:53 +08:00
|
|
|
if (test_bit(MD_RECOVERY_RESHAPE, &recovery))
|
2018-09-07 04:54:29 +08:00
|
|
|
return st_reshape;
|
2013-04-24 09:42:43 +08:00
|
|
|
|
2017-12-02 08:03:53 +08:00
|
|
|
if (test_bit(MD_RECOVERY_SYNC, &recovery)) {
|
|
|
|
if (!test_bit(MD_RECOVERY_REQUESTED, &recovery))
|
2018-09-07 04:54:29 +08:00
|
|
|
return st_resync;
|
|
|
|
if (test_bit(MD_RECOVERY_CHECK, &recovery))
|
|
|
|
return st_check;
|
|
|
|
return st_repair;
|
2013-04-24 09:42:43 +08:00
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:53 +08:00
|
|
|
if (test_bit(MD_RECOVERY_RECOVER, &recovery))
|
2018-09-07 04:54:29 +08:00
|
|
|
return st_recover;
|
|
|
|
|
|
|
|
if (mddev->reshape_position != MaxSector)
|
|
|
|
return st_reshape;
|
2013-04-24 09:42:43 +08:00
|
|
|
}
|
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
return st_idle;
|
2013-04-24 09:42:43 +08:00
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
2016-12-01 05:31:05 +08:00
|
|
|
* Return status string for @rdev
|
2016-05-20 00:49:34 +08:00
|
|
|
*
|
|
|
|
* Status characters:
|
|
|
|
*
|
2016-12-01 05:31:05 +08:00
|
|
|
* 'D' = Dead/Failed raid set component or raid4/5/6 journal device
|
2017-03-23 00:44:38 +08:00
|
|
|
* 'a' = Alive but not in-sync raid set component _or_ alive raid4/5/6 'write_back' journal device
|
|
|
|
* 'A' = Alive and in-sync raid set component _or_ alive raid4/5/6 'write_through' journal device
|
2017-01-14 10:53:07 +08:00
|
|
|
* '-' = Non-existing device (i.e. uspace passed '- -' into the ctr)
|
2016-05-20 00:49:34 +08:00
|
|
|
*/
|
2017-12-02 08:03:54 +08:00
|
|
|
static const char *__raid_dev_status(struct raid_set *rs, struct md_rdev *rdev)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2017-01-14 10:53:07 +08:00
|
|
|
if (!rdev->bdev)
|
|
|
|
return "-";
|
|
|
|
else if (test_bit(Faulty, &rdev->flags))
|
2016-05-20 00:49:34 +08:00
|
|
|
return "D";
|
2016-12-01 05:31:05 +08:00
|
|
|
else if (test_bit(Journal, &rdev->flags))
|
2017-03-23 00:44:38 +08:00
|
|
|
return (rs->journal_dev.mode == R5C_JOURNAL_MODE_WRITE_THROUGH) ? "A" : "a";
|
2017-12-02 08:03:55 +08:00
|
|
|
else if (test_bit(RT_FLAG_RS_RESYNCING, &rs->runtime_flags) ||
|
|
|
|
(!test_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags) &&
|
|
|
|
!test_bit(In_sync, &rdev->flags)))
|
2016-05-20 00:49:34 +08:00
|
|
|
return "a";
|
|
|
|
else
|
|
|
|
return "A";
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2017-12-02 08:03:54 +08:00
|
|
|
/* Helper to return resync/reshape progress for @rs and runtime flags for raid set in sync / resynching */
|
2017-12-02 08:03:53 +08:00
|
|
|
static sector_t rs_get_progress(struct raid_set *rs, unsigned long recovery,
|
2019-10-01 23:47:55 +08:00
|
|
|
enum sync_state state, sector_t resync_max_sectors)
|
2016-05-20 00:49:34 +08:00
|
|
|
{
|
2017-12-02 08:03:55 +08:00
|
|
|
sector_t r;
|
2016-05-20 00:49:34 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2017-12-02 08:03:54 +08:00
|
|
|
clear_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
2017-12-02 08:03:55 +08:00
|
|
|
clear_bit(RT_FLAG_RS_RESYNCING, &rs->runtime_flags);
|
2016-05-20 00:49:34 +08:00
|
|
|
|
|
|
|
if (rs_is_raid0(rs)) {
|
|
|
|
r = resync_max_sectors;
|
2017-12-02 08:03:54 +08:00
|
|
|
set_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
2016-05-20 00:49:34 +08:00
|
|
|
|
|
|
|
} else {
|
2018-09-07 04:54:29 +08:00
|
|
|
if (state == st_idle && !test_bit(MD_RECOVERY_INTR, &recovery))
|
2017-10-03 06:17:35 +08:00
|
|
|
r = mddev->recovery_cp;
|
2018-09-07 04:54:29 +08:00
|
|
|
else
|
|
|
|
r = mddev->curr_resync_completed;
|
2016-05-20 00:49:34 +08:00
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
if (state == st_idle && r >= resync_max_sectors) {
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
|
|
|
* Sync complete.
|
|
|
|
*/
|
2017-12-02 08:03:55 +08:00
|
|
|
/* In case we have finished recovering, the array is in sync. */
|
|
|
|
if (test_bit(MD_RECOVERY_RECOVER, &recovery))
|
|
|
|
set_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
} else if (state == st_recover)
|
2017-12-02 08:03:55 +08:00
|
|
|
/*
|
|
|
|
* In case we are recovering, the array is not in sync
|
|
|
|
* and health chars should show the recovering legs.
|
2019-10-01 23:47:55 +08:00
|
|
|
*
|
|
|
|
* Already retrieved recovery offset from curr_resync_completed above.
|
2017-12-02 08:03:55 +08:00
|
|
|
*/
|
|
|
|
;
|
2019-10-01 23:47:55 +08:00
|
|
|
|
|
|
|
else if (state == st_resync || state == st_reshape)
|
2017-12-14 00:13:19 +08:00
|
|
|
/*
|
2019-10-01 23:47:55 +08:00
|
|
|
* If "resync/reshape" is occurring, the raid set
|
2017-12-14 00:13:19 +08:00
|
|
|
* is or may be out of sync hence the health
|
|
|
|
* characters shall be 'a'.
|
|
|
|
*/
|
|
|
|
set_bit(RT_FLAG_RS_RESYNCING, &rs->runtime_flags);
|
|
|
|
|
2018-09-07 04:54:29 +08:00
|
|
|
else if (state == st_check || state == st_repair)
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
|
|
|
* If "check" or "repair" is occurring, the raid set has
|
|
|
|
* undergone an initial sync and the health characters
|
|
|
|
* should not be 'a' anymore.
|
|
|
|
*/
|
2017-12-02 08:03:54 +08:00
|
|
|
set_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
2017-12-02 08:03:55 +08:00
|
|
|
|
2019-10-01 23:47:55 +08:00
|
|
|
else if (test_bit(MD_RECOVERY_NEEDED, &recovery))
|
2017-12-02 08:03:55 +08:00
|
|
|
/*
|
|
|
|
* We are idle and recovery is needed, prevent 'A' chars race
|
2018-09-07 04:54:29 +08:00
|
|
|
* caused by components still set to in-sync by constructor.
|
2017-12-02 08:03:55 +08:00
|
|
|
*/
|
2019-10-01 23:47:55 +08:00
|
|
|
set_bit(RT_FLAG_RS_RESYNCING, &rs->runtime_flags);
|
2017-12-02 08:03:55 +08:00
|
|
|
|
2019-10-01 23:47:55 +08:00
|
|
|
else {
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
2019-10-01 23:47:55 +08:00
|
|
|
* We are idle and the raid set may be doing an initial
|
|
|
|
* sync, or it may be rebuilding individual components.
|
|
|
|
* If all the devices are In_sync, then it is the raid set
|
|
|
|
* that is being initialized.
|
2016-05-20 00:49:34 +08:00
|
|
|
*/
|
2019-10-01 23:47:55 +08:00
|
|
|
struct md_rdev *rdev;
|
|
|
|
|
2017-12-02 08:03:55 +08:00
|
|
|
set_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
2016-05-20 00:49:34 +08:00
|
|
|
rdev_for_each(rdev, mddev)
|
2016-12-01 05:31:05 +08:00
|
|
|
if (!test_bit(Journal, &rdev->flags) &&
|
2017-12-02 08:03:55 +08:00
|
|
|
!test_bit(In_sync, &rdev->flags)) {
|
|
|
|
clear_bit(RT_FLAG_RS_IN_SYNC, &rs->runtime_flags);
|
|
|
|
break;
|
|
|
|
}
|
2011-11-01 04:21:26 +08:00
|
|
|
}
|
2016-05-20 00:49:34 +08:00
|
|
|
}
|
|
|
|
|
2017-12-02 08:03:55 +08:00
|
|
|
return min(r, resync_max_sectors);
|
2016-05-20 00:49:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Helper to return @dev name or "-" if !@dev */
|
2016-06-03 03:27:22 +08:00
|
|
|
static const char *__get_dev_name(struct dm_dev *dev)
|
2016-05-20 00:49:34 +08:00
|
|
|
{
|
|
|
|
return dev ? dev->name : "-";
|
|
|
|
}
|
|
|
|
|
|
|
|
static void raid_status(struct dm_target *ti, status_type_t type,
|
|
|
|
unsigned int status_flags, char *result, unsigned int maxlen)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
|
|
|
struct mddev *mddev = &rs->md;
|
2022-07-25 02:31:35 +08:00
|
|
|
struct r5conf *conf = rs_is_raid456(rs) ? mddev->private : NULL;
|
2016-06-30 19:57:08 +08:00
|
|
|
int i, max_nr_stripes = conf ? conf->max_nr_stripes : 0;
|
2017-12-02 08:03:53 +08:00
|
|
|
unsigned long recovery;
|
2016-05-20 00:49:34 +08:00
|
|
|
unsigned int raid_param_cnt = 1; /* at least 1 for chunksize */
|
|
|
|
unsigned int sz = 0;
|
2019-12-20 00:58:46 +08:00
|
|
|
unsigned int rebuild_writemostly_count = 0;
|
2016-05-20 00:49:34 +08:00
|
|
|
sector_t progress, resync_max_sectors, resync_mismatches;
|
2019-10-01 23:47:55 +08:00
|
|
|
enum sync_state state;
|
2016-05-20 00:49:34 +08:00
|
|
|
struct raid_type *rt;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case STATUSTYPE_INFO:
|
|
|
|
/* *Should* always succeed */
|
|
|
|
rt = get_raid_type_by_ll(mddev->new_level, mddev->new_layout);
|
|
|
|
if (!rt)
|
|
|
|
return;
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
DMEMIT("%s %d ", rt->name, mddev->raid_disks);
|
2016-05-20 00:49:34 +08:00
|
|
|
|
|
|
|
/* Access most recent mddev properties for status output */
|
|
|
|
smp_rmb();
|
|
|
|
/* Get sensible max sectors even if raid set not yet started */
|
2016-06-03 00:27:46 +08:00
|
|
|
resync_max_sectors = test_bit(RT_FLAG_RS_PRERESUMED, &rs->runtime_flags) ?
|
2016-05-20 00:49:34 +08:00
|
|
|
mddev->resync_max_sectors : mddev->dev_sectors;
|
2019-10-01 23:47:55 +08:00
|
|
|
recovery = rs->md.recovery;
|
|
|
|
state = decipher_sync_action(mddev, recovery);
|
|
|
|
progress = rs_get_progress(rs, recovery, state, resync_max_sectors);
|
2016-05-20 00:49:34 +08:00
|
|
|
resync_mismatches = (mddev->last_sync_action && !strcasecmp(mddev->last_sync_action, "check")) ?
|
2016-06-13 23:55:14 +08:00
|
|
|
atomic64_read(&mddev->resync_mismatches) : 0;
|
2016-05-20 00:49:34 +08:00
|
|
|
|
2017-01-14 10:53:07 +08:00
|
|
|
/* HM FIXME: do we want another state char for raid0? It shows 'D'/'A'/'-' now */
|
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
2017-12-02 08:03:54 +08:00
|
|
|
DMEMIT(__raid_dev_status(rs, &rs->dev[i].rdev));
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2011-11-01 04:21:26 +08:00
|
|
|
/*
|
2016-05-20 00:49:34 +08:00
|
|
|
* In-sync/Reshape ratio:
|
2011-11-01 04:21:26 +08:00
|
|
|
* The in-sync ratio shows the progress of:
|
2016-05-20 00:49:34 +08:00
|
|
|
* - Initializing the raid set
|
|
|
|
* - Rebuilding a subset of devices of the raid set
|
2011-11-01 04:21:26 +08:00
|
|
|
* The user can distinguish between the two by referring
|
|
|
|
* to the status characters.
|
2016-05-20 00:49:34 +08:00
|
|
|
*
|
|
|
|
* The reshape ratio shows the progress of
|
|
|
|
* changing the raid layout or the number of
|
|
|
|
* disks of a raid set
|
2011-11-01 04:21:26 +08:00
|
|
|
*/
|
2016-05-20 00:49:34 +08:00
|
|
|
DMEMIT(" %llu/%llu", (unsigned long long) progress,
|
|
|
|
(unsigned long long) resync_max_sectors);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2013-04-24 09:42:43 +08:00
|
|
|
/*
|
2016-05-20 00:49:34 +08:00
|
|
|
* v1.5.0+:
|
|
|
|
*
|
2013-04-24 09:42:43 +08:00
|
|
|
* Sync action:
|
2019-06-18 23:40:23 +08:00
|
|
|
* See Documentation/admin-guide/device-mapper/dm-raid.rst for
|
2013-04-24 09:42:43 +08:00
|
|
|
* information on each of these states.
|
|
|
|
*/
|
2019-10-01 23:47:55 +08:00
|
|
|
DMEMIT(" %s", sync_str(state));
|
2013-04-24 09:42:43 +08:00
|
|
|
|
|
|
|
/*
|
2016-05-20 00:49:34 +08:00
|
|
|
* v1.5.0+:
|
|
|
|
*
|
2013-04-24 09:42:43 +08:00
|
|
|
* resync_mismatches/mismatch_cnt
|
|
|
|
* This field shows the number of discrepancies found when
|
2016-05-20 00:49:34 +08:00
|
|
|
* performing a "check" of the raid set.
|
2013-04-24 09:42:43 +08:00
|
|
|
*/
|
2016-05-20 00:49:34 +08:00
|
|
|
DMEMIT(" %llu", (unsigned long long) resync_mismatches);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:34 +08:00
|
|
|
/*
|
2016-06-02 23:48:09 +08:00
|
|
|
* v1.9.0+:
|
2016-05-20 00:49:34 +08:00
|
|
|
*
|
|
|
|
* data_offset (needed for out of space reshaping)
|
|
|
|
* This field shows the data offset into the data
|
|
|
|
* image LV where the first stripes data starts.
|
|
|
|
*
|
|
|
|
* We keep data_offset equal on all raid disks of the set,
|
|
|
|
* so retrieving it from the first raid disk is sufficient.
|
|
|
|
*/
|
|
|
|
DMEMIT(" %llu", (unsigned long long) rs->dev[0].rdev.data_offset);
|
2016-12-01 05:31:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* v1.10.0+:
|
|
|
|
*/
|
|
|
|
DMEMIT(" %s", test_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags) ?
|
2017-12-02 08:03:54 +08:00
|
|
|
__raid_dev_status(rs, &rs->journal_dev.rdev) : "-");
|
2016-05-20 00:49:34 +08:00
|
|
|
break;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:34 +08:00
|
|
|
case STATUSTYPE_TABLE:
|
|
|
|
/* Report the table line string you would use to construct this raid set */
|
|
|
|
|
2019-12-20 00:58:46 +08:00
|
|
|
/*
|
|
|
|
* Count any rebuild or writemostly argument pairs and subtract the
|
|
|
|
* hweight count being added below of any rebuild and writemostly ctr flags.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
|
|
|
rebuild_writemostly_count += (test_bit(i, (void *) rs->rebuild_disks) ? 2 : 0) +
|
|
|
|
(test_bit(WriteMostly, &rs->dev[i].rdev.flags) ? 2 : 0);
|
|
|
|
}
|
|
|
|
rebuild_writemostly_count -= (test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags) ? 2 : 0) +
|
|
|
|
(test_bit(__CTR_FLAG_WRITE_MOSTLY, &rs->ctr_flags) ? 2 : 0);
|
|
|
|
/* Calculate raid parameter count based on ^ rebuild/writemostly argument counts and ctr flags set. */
|
|
|
|
raid_param_cnt += rebuild_writemostly_count +
|
2016-05-20 00:49:34 +08:00
|
|
|
hweight32(rs->ctr_flags & CTR_FLAG_OPTIONS_NO_ARGS) +
|
2019-12-20 00:58:46 +08:00
|
|
|
hweight32(rs->ctr_flags & CTR_FLAG_OPTIONS_ONE_ARG) * 2;
|
2016-05-20 00:49:34 +08:00
|
|
|
/* Emit table line */
|
2017-03-18 08:39:12 +08:00
|
|
|
/* This has to be in the documented order for userspace! */
|
2016-05-20 00:49:34 +08:00
|
|
|
DMEMIT("%s %u %u", rs->raid_type->name, raid_param_cnt, mddev->new_chunk_sectors);
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags))
|
2016-06-02 23:58:51 +08:00
|
|
|
DMEMIT(" %s", dm_raid_arg_name_by_flag(CTR_FLAG_SYNC));
|
2017-03-18 08:39:12 +08:00
|
|
|
if (test_bit(__CTR_FLAG_NOSYNC, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s", dm_raid_arg_name_by_flag(CTR_FLAG_NOSYNC));
|
2019-12-20 00:58:46 +08:00
|
|
|
if (test_bit(__CTR_FLAG_REBUILD, &rs->ctr_flags))
|
2016-06-30 19:57:08 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
2019-12-20 00:58:46 +08:00
|
|
|
if (test_bit(i, (void *) rs->rebuild_disks))
|
|
|
|
DMEMIT(" %s %u", dm_raid_arg_name_by_flag(CTR_FLAG_REBUILD), i);
|
2017-03-18 08:39:12 +08:00
|
|
|
if (test_bit(__CTR_FLAG_DAEMON_SLEEP, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %lu", dm_raid_arg_name_by_flag(CTR_FLAG_DAEMON_SLEEP),
|
|
|
|
mddev->bitmap_info.daemon_sleep);
|
|
|
|
if (test_bit(__CTR_FLAG_MIN_RECOVERY_RATE, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_MIN_RECOVERY_RATE),
|
|
|
|
mddev->sync_speed_min);
|
|
|
|
if (test_bit(__CTR_FLAG_MAX_RECOVERY_RATE, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_MAX_RECOVERY_RATE),
|
|
|
|
mddev->sync_speed_max);
|
2019-12-20 00:58:46 +08:00
|
|
|
if (test_bit(__CTR_FLAG_WRITE_MOSTLY, &rs->ctr_flags))
|
2016-06-30 19:57:08 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
|
|
|
if (test_bit(WriteMostly, &rs->dev[i].rdev.flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_WRITE_MOSTLY),
|
|
|
|
rs->dev[i].rdev.raid_disk);
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_bit(__CTR_FLAG_MAX_WRITE_BEHIND, &rs->ctr_flags))
|
2016-06-02 23:58:51 +08:00
|
|
|
DMEMIT(" %s %lu", dm_raid_arg_name_by_flag(CTR_FLAG_MAX_WRITE_BEHIND),
|
2016-05-20 00:49:34 +08:00
|
|
|
mddev->bitmap_info.max_write_behind);
|
2017-03-18 08:39:12 +08:00
|
|
|
if (test_bit(__CTR_FLAG_STRIPE_CACHE, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_STRIPE_CACHE),
|
|
|
|
max_nr_stripes);
|
|
|
|
if (test_bit(__CTR_FLAG_REGION_SIZE, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %llu", dm_raid_arg_name_by_flag(CTR_FLAG_REGION_SIZE),
|
|
|
|
(unsigned long long) to_sector(mddev->bitmap_info.chunksize));
|
|
|
|
if (test_bit(__CTR_FLAG_RAID10_COPIES, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_RAID10_COPIES),
|
|
|
|
raid10_md_layout_to_copies(mddev->layout));
|
|
|
|
if (test_bit(__CTR_FLAG_RAID10_FORMAT, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %s", dm_raid_arg_name_by_flag(CTR_FLAG_RAID10_FORMAT),
|
|
|
|
raid10_md_layout_to_format(mddev->layout));
|
|
|
|
if (test_bit(__CTR_FLAG_DELTA_DISKS, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %d", dm_raid_arg_name_by_flag(CTR_FLAG_DELTA_DISKS),
|
|
|
|
max(rs->delta_disks, mddev->delta_disks));
|
|
|
|
if (test_bit(__CTR_FLAG_DATA_OFFSET, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %llu", dm_raid_arg_name_by_flag(CTR_FLAG_DATA_OFFSET),
|
|
|
|
(unsigned long long) rs->data_offset);
|
2016-12-01 05:31:05 +08:00
|
|
|
if (test_bit(__CTR_FLAG_JOURNAL_DEV, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %s", dm_raid_arg_name_by_flag(CTR_FLAG_JOURNAL_DEV),
|
|
|
|
__get_dev_name(rs->journal_dev.dev));
|
2017-03-23 00:44:38 +08:00
|
|
|
if (test_bit(__CTR_FLAG_JOURNAL_MODE, &rs->ctr_flags))
|
|
|
|
DMEMIT(" %s %s", dm_raid_arg_name_by_flag(CTR_FLAG_JOURNAL_MODE),
|
|
|
|
md_journal_mode_to_dm_raid(rs->journal_dev.mode));
|
2016-05-20 00:49:34 +08:00
|
|
|
DMEMIT(" %d", rs->raid_disks);
|
2016-06-30 19:57:08 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++)
|
|
|
|
DMEMIT(" %s %s", __get_dev_name(rs->dev[i].meta_dev),
|
|
|
|
__get_dev_name(rs->dev[i].data_dev));
|
2021-07-13 08:49:03 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case STATUSTYPE_IMA:
|
|
|
|
rt = get_raid_type_by_ll(mddev->new_level, mddev->new_layout);
|
|
|
|
if (!rt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
DMEMIT_TARGET_NAME_VERSION(ti->type);
|
|
|
|
DMEMIT(",raid_type=%s,raid_disks=%d", rt->name, mddev->raid_disks);
|
|
|
|
|
|
|
|
/* Access most recent mddev properties for status output */
|
|
|
|
smp_rmb();
|
|
|
|
recovery = rs->md.recovery;
|
|
|
|
state = decipher_sync_action(mddev, recovery);
|
|
|
|
DMEMIT(",raid_state=%s", sync_str(state));
|
|
|
|
|
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
|
|
|
DMEMIT(",raid_device_%d_status=", i);
|
|
|
|
DMEMIT(__raid_dev_status(rs, &rs->dev[i].rdev));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rt_is_raid456(rt)) {
|
|
|
|
DMEMIT(",journal_dev_mode=");
|
|
|
|
switch (rs->journal_dev.mode) {
|
|
|
|
case R5C_JOURNAL_MODE_WRITE_THROUGH:
|
|
|
|
DMEMIT("%s",
|
|
|
|
_raid456_journal_mode[R5C_JOURNAL_MODE_WRITE_THROUGH].param);
|
|
|
|
break;
|
|
|
|
case R5C_JOURNAL_MODE_WRITE_BACK:
|
|
|
|
DMEMIT("%s",
|
|
|
|
_raid456_journal_mode[R5C_JOURNAL_MODE_WRITE_BACK].param);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
DMEMIT("invalid");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
DMEMIT(";");
|
|
|
|
break;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-01 04:59:59 +08:00
|
|
|
static int raid_message(struct dm_target *ti, unsigned int argc, char **argv,
|
|
|
|
char *result, unsigned maxlen)
|
2013-04-24 09:42:43 +08:00
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
|
|
|
if (!mddev->pers || !mddev->pers->sync_request)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcasecmp(argv[0], "frozen"))
|
|
|
|
set_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
|
|
|
|
else
|
|
|
|
clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
|
|
|
|
|
|
|
|
if (!strcasecmp(argv[0], "idle") || !strcasecmp(argv[0], "frozen")) {
|
|
|
|
if (mddev->sync_thread) {
|
|
|
|
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
|
2022-06-21 11:11:29 +08:00
|
|
|
md_unregister_thread(&mddev->sync_thread);
|
2022-06-07 10:03:56 +08:00
|
|
|
md_reap_sync_thread(mddev);
|
2013-04-24 09:42:43 +08:00
|
|
|
}
|
2018-12-19 00:35:41 +08:00
|
|
|
} else if (decipher_sync_action(mddev, mddev->recovery) != st_idle)
|
2013-04-24 09:42:43 +08:00
|
|
|
return -EBUSY;
|
|
|
|
else if (!strcasecmp(argv[0], "resync"))
|
2016-05-20 00:49:34 +08:00
|
|
|
; /* MD_RECOVERY_NEEDED set below */
|
|
|
|
else if (!strcasecmp(argv[0], "recover"))
|
2013-04-24 09:42:43 +08:00
|
|
|
set_bit(MD_RECOVERY_RECOVER, &mddev->recovery);
|
2016-05-20 00:49:34 +08:00
|
|
|
else {
|
2017-03-01 00:55:16 +08:00
|
|
|
if (!strcasecmp(argv[0], "check")) {
|
2013-04-24 09:42:43 +08:00
|
|
|
set_bit(MD_RECOVERY_CHECK, &mddev->recovery);
|
2017-03-01 00:55:16 +08:00
|
|
|
set_bit(MD_RECOVERY_REQUESTED, &mddev->recovery);
|
|
|
|
set_bit(MD_RECOVERY_SYNC, &mddev->recovery);
|
|
|
|
} else if (!strcasecmp(argv[0], "repair")) {
|
2017-01-07 04:38:08 +08:00
|
|
|
set_bit(MD_RECOVERY_REQUESTED, &mddev->recovery);
|
|
|
|
set_bit(MD_RECOVERY_SYNC, &mddev->recovery);
|
|
|
|
} else
|
2013-04-24 09:42:43 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (mddev->ro == 2) {
|
|
|
|
/* A write to sync_action is enough to justify
|
|
|
|
* canceling read-auto mode
|
|
|
|
*/
|
|
|
|
mddev->ro = 0;
|
2016-05-20 00:49:34 +08:00
|
|
|
if (!mddev->suspended && mddev->sync_thread)
|
2013-04-24 09:42:43 +08:00
|
|
|
md_wakeup_thread(mddev->sync_thread);
|
|
|
|
}
|
|
|
|
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
|
2016-05-20 00:49:34 +08:00
|
|
|
if (!mddev->suspended && mddev->thread)
|
2013-04-24 09:42:43 +08:00
|
|
|
md_wakeup_thread(mddev->thread);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int raid_iterate_devices(struct dm_target *ti,
|
|
|
|
iterate_devices_callout_fn fn, void *data)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
2016-07-19 20:03:51 +08:00
|
|
|
unsigned int i;
|
2016-05-20 00:49:24 +08:00
|
|
|
int r = 0;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2022-06-28 06:37:22 +08:00
|
|
|
for (i = 0; !r && i < rs->raid_disks; i++) {
|
|
|
|
if (rs->dev[i].data_dev) {
|
|
|
|
r = fn(ti, rs->dev[i].data_dev,
|
|
|
|
0, /* No offset on data devs */
|
|
|
|
rs->md.dev_sectors, data);
|
|
|
|
}
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-05-20 00:49:24 +08:00
|
|
|
return r;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
dm raid: fix updating of max_discard_sectors limit
Unit of 'chunk_size' is byte, instead of sector, so fix it by setting
the queue_limits' max_discard_sectors to rs->md.chunk_sectors. Also,
rename chunk_size to chunk_size_bytes.
Without this fix, too big max_discard_sectors is applied on the request
queue of dm-raid, finally raid code has to split the bio again.
This re-split done by raid causes the following nested clone_endio:
1) one big bio 'A' is submitted to dm queue, and served as the original
bio
2) one new bio 'B' is cloned from the original bio 'A', and .map()
is run on this bio of 'B', and B's original bio points to 'A'
3) raid code sees that 'B' is too big, and split 'B' and re-submit
the remainded part of 'B' to dm-raid queue via generic_make_request().
4) now dm will handle 'B' as new original bio, then allocate a new
clone bio of 'C' and run .map() on 'C'. Meantime C's original bio
points to 'B'.
5) suppose now 'C' is completed by raid directly, then the following
clone_endio() is called recursively:
clone_endio(C)
->clone_endio(B) #B is original bio of 'C'
->bio_endio(A)
'A' can be big enough to make hundreds of nested clone_endio(), then
stack can be corrupted easily.
Fixes: 61697a6abd24a ("dm: eliminate 'split_discard_bios' flag from DM target interface")
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2019-09-11 19:31:33 +08:00
|
|
|
unsigned int chunk_size_bytes = to_bytes(rs->md.chunk_sectors);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
dm raid: fix updating of max_discard_sectors limit
Unit of 'chunk_size' is byte, instead of sector, so fix it by setting
the queue_limits' max_discard_sectors to rs->md.chunk_sectors. Also,
rename chunk_size to chunk_size_bytes.
Without this fix, too big max_discard_sectors is applied on the request
queue of dm-raid, finally raid code has to split the bio again.
This re-split done by raid causes the following nested clone_endio:
1) one big bio 'A' is submitted to dm queue, and served as the original
bio
2) one new bio 'B' is cloned from the original bio 'A', and .map()
is run on this bio of 'B', and B's original bio points to 'A'
3) raid code sees that 'B' is too big, and split 'B' and re-submit
the remainded part of 'B' to dm-raid queue via generic_make_request().
4) now dm will handle 'B' as new original bio, then allocate a new
clone bio of 'C' and run .map() on 'C'. Meantime C's original bio
points to 'B'.
5) suppose now 'C' is completed by raid directly, then the following
clone_endio() is called recursively:
clone_endio(C)
->clone_endio(B) #B is original bio of 'C'
->bio_endio(A)
'A' can be big enough to make hundreds of nested clone_endio(), then
stack can be corrupted easily.
Fixes: 61697a6abd24a ("dm: eliminate 'split_discard_bios' flag from DM target interface")
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2019-09-11 19:31:33 +08:00
|
|
|
blk_limits_io_min(limits, chunk_size_bytes);
|
|
|
|
blk_limits_io_opt(limits, chunk_size_bytes * mddev_data_stripes(rs));
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void raid_postsuspend(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
|
|
|
|
2017-10-19 09:17:16 +08:00
|
|
|
if (!test_and_set_bit(RT_FLAG_RS_SUSPENDED, &rs->runtime_flags)) {
|
2017-12-02 08:03:48 +08:00
|
|
|
/* Writes have to be stopped before suspending to avoid deadlocks. */
|
|
|
|
if (!test_bit(MD_RECOVERY_FROZEN, &rs->md.recovery))
|
|
|
|
md_stop_writes(&rs->md);
|
|
|
|
|
2017-10-19 09:17:16 +08:00
|
|
|
mddev_lock_nointr(&rs->md);
|
2016-08-10 08:45:59 +08:00
|
|
|
mddev_suspend(&rs->md);
|
2017-10-19 09:17:16 +08:00
|
|
|
mddev_unlock(&rs->md);
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
2013-05-09 06:57:13 +08:00
|
|
|
static void attempt_restore_of_faulty_devices(struct raid_set *rs)
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
{
|
2013-05-03 03:19:24 +08:00
|
|
|
int i;
|
2016-08-09 20:55:35 +08:00
|
|
|
uint64_t cleared_failed_devices[DISKS_ARRAY_ELEMS];
|
2013-05-03 03:19:24 +08:00
|
|
|
unsigned long flags;
|
2016-08-09 20:55:35 +08:00
|
|
|
bool cleared = false;
|
2013-05-03 03:19:24 +08:00
|
|
|
struct dm_raid_superblock *sb;
|
2016-08-09 20:55:35 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
2013-05-03 03:19:24 +08:00
|
|
|
struct md_rdev *r;
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
|
2016-08-09 20:55:35 +08:00
|
|
|
/* RAID personalities have to provide hot add/remove methods or we need to bail out. */
|
|
|
|
if (!mddev->pers || !mddev->pers->hot_add_disk || !mddev->pers->hot_remove_disk)
|
|
|
|
return;
|
|
|
|
|
|
|
|
memset(cleared_failed_devices, 0, sizeof(cleared_failed_devices));
|
|
|
|
|
2022-07-25 02:33:52 +08:00
|
|
|
for (i = 0; i < rs->raid_disks; i++) {
|
2013-05-09 06:57:13 +08:00
|
|
|
r = &rs->dev[i].rdev;
|
2016-12-01 05:31:05 +08:00
|
|
|
/* HM FIXME: enhance journal device recovery processing */
|
|
|
|
if (test_bit(Journal, &r->flags))
|
|
|
|
continue;
|
|
|
|
|
2017-01-14 10:53:10 +08:00
|
|
|
if (test_bit(Faulty, &r->flags) &&
|
|
|
|
r->meta_bdev && !read_disk_sb(r, r->sb_size, true)) {
|
2013-05-09 06:57:13 +08:00
|
|
|
DMINFO("Faulty %s device #%d has readable super block."
|
|
|
|
" Attempting to revive it.",
|
|
|
|
rs->raid_type->name, i);
|
DM RAID: Fix raid_resume not reviving failed devices in all cases
DM RAID: Fix raid_resume not reviving failed devices in all cases
When a device fails in a RAID array, it is marked as Faulty. Later,
md_check_recovery is called which (through the call chain) calls
'hot_remove_disk' in order to have the personalities remove the device
from use in the array.
Sometimes, it is possible for the array to be suspended before the
personalities get their chance to perform 'hot_remove_disk'. This is
normally not an issue. If the array is deactivated, then the failed
device will be noticed when the array is reinstantiated. If the
array is resumed and the disk is still missing, md_check_recovery will
be called upon resume and 'hot_remove_disk' will be called at that
time. However, (for dm-raid) if the device has been restored,
a resume on the array would cause it to attempt to revive the device
by calling 'hot_add_disk'. If 'hot_remove_disk' had not been called,
a situation is then created where the device is thought to concurrently
be the replacement and the device to be replaced. Thus, the device
is first sync'ed with the rest of the array (because it is the replacement
device) and then marked Faulty and removed from the array (because
it is also the device being replaced).
The solution is to check and see if the device had properly been removed
before the array was suspended. This is done by seeing whether the
device's 'raid_disk' field is -1 - a condition that implies that
'md_check_recovery -> remove_and_add_spares (where raid_disk is set to -1)
-> hot_remove_disk' has been called. If 'raid_disk' is not -1, then
'hot_remove_disk' must be called to complete the removal of the previously
faulty device before it can be revived via 'hot_add_disk'.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-05-09 07:00:54 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Faulty bit may be set, but sometimes the array can
|
|
|
|
* be suspended before the personalities can respond
|
|
|
|
* by removing the device from the array (i.e. calling
|
2016-05-31 01:03:37 +08:00
|
|
|
* 'hot_remove_disk'). If they haven't yet removed
|
DM RAID: Fix raid_resume not reviving failed devices in all cases
DM RAID: Fix raid_resume not reviving failed devices in all cases
When a device fails in a RAID array, it is marked as Faulty. Later,
md_check_recovery is called which (through the call chain) calls
'hot_remove_disk' in order to have the personalities remove the device
from use in the array.
Sometimes, it is possible for the array to be suspended before the
personalities get their chance to perform 'hot_remove_disk'. This is
normally not an issue. If the array is deactivated, then the failed
device will be noticed when the array is reinstantiated. If the
array is resumed and the disk is still missing, md_check_recovery will
be called upon resume and 'hot_remove_disk' will be called at that
time. However, (for dm-raid) if the device has been restored,
a resume on the array would cause it to attempt to revive the device
by calling 'hot_add_disk'. If 'hot_remove_disk' had not been called,
a situation is then created where the device is thought to concurrently
be the replacement and the device to be replaced. Thus, the device
is first sync'ed with the rest of the array (because it is the replacement
device) and then marked Faulty and removed from the array (because
it is also the device being replaced).
The solution is to check and see if the device had properly been removed
before the array was suspended. This is done by seeing whether the
device's 'raid_disk' field is -1 - a condition that implies that
'md_check_recovery -> remove_and_add_spares (where raid_disk is set to -1)
-> hot_remove_disk' has been called. If 'raid_disk' is not -1, then
'hot_remove_disk' must be called to complete the removal of the previously
faulty device before it can be revived via 'hot_add_disk'.
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
2013-05-09 07:00:54 +08:00
|
|
|
* the failed device, its 'raid_disk' number will be
|
|
|
|
* '>= 0' - meaning we must call this function
|
|
|
|
* ourselves.
|
|
|
|
*/
|
2013-05-09 06:57:13 +08:00
|
|
|
flags = r->flags;
|
2017-01-14 10:53:07 +08:00
|
|
|
clear_bit(In_sync, &r->flags); /* Mandatory for hot remove. */
|
|
|
|
if (r->raid_disk >= 0) {
|
|
|
|
if (mddev->pers->hot_remove_disk(mddev, r)) {
|
|
|
|
/* Failed to revive this device, try next */
|
|
|
|
r->flags = flags;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
r->raid_disk = r->saved_raid_disk = i;
|
|
|
|
|
2013-05-09 06:57:13 +08:00
|
|
|
clear_bit(Faulty, &r->flags);
|
|
|
|
clear_bit(WriteErrorSeen, &r->flags);
|
2017-01-14 10:53:07 +08:00
|
|
|
|
2016-08-09 20:55:35 +08:00
|
|
|
if (mddev->pers->hot_add_disk(mddev, r)) {
|
2017-01-14 10:53:07 +08:00
|
|
|
/* Failed to revive this device, try next */
|
|
|
|
r->raid_disk = r->saved_raid_disk = -1;
|
2013-05-09 06:57:13 +08:00
|
|
|
r->flags = flags;
|
|
|
|
} else {
|
2017-01-14 10:53:07 +08:00
|
|
|
clear_bit(In_sync, &r->flags);
|
2013-05-09 06:57:13 +08:00
|
|
|
r->recovery_offset = 0;
|
2016-08-09 20:55:35 +08:00
|
|
|
set_bit(i, (void *) cleared_failed_devices);
|
|
|
|
cleared = true;
|
2013-05-09 06:57:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-08-09 20:55:35 +08:00
|
|
|
|
|
|
|
/* If any failed devices could be cleared, update all sbs failed_devices bits */
|
|
|
|
if (cleared) {
|
|
|
|
uint64_t failed_devices[DISKS_ARRAY_ELEMS];
|
|
|
|
|
2013-05-09 06:57:13 +08:00
|
|
|
rdev_for_each(r, &rs->md) {
|
2016-12-01 05:31:05 +08:00
|
|
|
if (test_bit(Journal, &r->flags))
|
|
|
|
continue;
|
|
|
|
|
2013-05-09 06:57:13 +08:00
|
|
|
sb = page_address(r->sb_page);
|
2016-08-09 20:55:35 +08:00
|
|
|
sb_retrieve_failed_devices(sb, failed_devices);
|
|
|
|
|
|
|
|
for (i = 0; i < DISKS_ARRAY_ELEMS; i++)
|
|
|
|
failed_devices[i] &= ~cleared_failed_devices[i];
|
|
|
|
|
|
|
|
sb_update_failed_devices(sb, failed_devices);
|
2013-05-09 06:57:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-03 03:27:22 +08:00
|
|
|
static int __load_dirty_region_bitmap(struct raid_set *rs)
|
2016-05-20 00:49:33 +08:00
|
|
|
{
|
|
|
|
int r = 0;
|
|
|
|
|
|
|
|
/* Try loading the bitmap unless "raid0", which does not have one */
|
|
|
|
if (!rs_is_raid0(rs) &&
|
2016-06-03 00:27:46 +08:00
|
|
|
!test_and_set_bit(RT_FLAG_RS_BITMAP_LOADED, &rs->runtime_flags)) {
|
2018-08-02 06:20:50 +08:00
|
|
|
r = md_bitmap_load(&rs->md);
|
2016-05-20 00:49:33 +08:00
|
|
|
if (r)
|
|
|
|
DMERR("Failed to load bitmap");
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2016-06-15 03:23:13 +08:00
|
|
|
/* Enforce updating all superblocks */
|
|
|
|
static void rs_update_sbs(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
int ro = mddev->ro;
|
|
|
|
|
2016-12-09 07:48:19 +08:00
|
|
|
set_bit(MD_SB_CHANGE_DEVS, &mddev->sb_flags);
|
2016-06-15 03:23:13 +08:00
|
|
|
mddev->ro = 0;
|
|
|
|
md_update_sb(mddev, 1);
|
|
|
|
mddev->ro = ro;
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/*
|
|
|
|
* Reshape changes raid algorithm of @rs to new one within personality
|
|
|
|
* (e.g. raid6_zr -> raid6_nc), changes stripe size, adds/removes
|
|
|
|
* disks from a raid set thus growing/shrinking it or resizes the set
|
|
|
|
*
|
|
|
|
* Call mddev_lock_nointr() before!
|
|
|
|
*/
|
|
|
|
static int rs_start_reshape(struct raid_set *rs)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
struct md_personality *pers = mddev->pers;
|
|
|
|
|
2018-09-07 00:33:39 +08:00
|
|
|
/* Don't allow the sync thread to work until the table gets reloaded. */
|
|
|
|
set_bit(MD_RECOVERY_WAIT, &mddev->recovery);
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
r = rs_setup_reshape(rs);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check any reshape constraints enforced by the personalility
|
|
|
|
*
|
|
|
|
* May as well already kick the reshape off so that * pers->start_reshape() becomes optional.
|
|
|
|
*/
|
|
|
|
r = pers->check_reshape(mddev);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "pers->check_reshape() failed";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Personality may not provide start reshape method in which
|
|
|
|
* case check_reshape above has already covered everything
|
|
|
|
*/
|
|
|
|
if (pers->start_reshape) {
|
|
|
|
r = pers->start_reshape(mddev);
|
|
|
|
if (r) {
|
|
|
|
rs->ti->error = "pers->start_reshape() failed";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-15 03:23:13 +08:00
|
|
|
/*
|
|
|
|
* Now reshape got set up, update superblocks to
|
|
|
|
* reflect the fact so that a table reload will
|
|
|
|
* access proper superblock content in the ctr.
|
|
|
|
*/
|
|
|
|
rs_update_sbs(rs);
|
2016-06-13 23:55:14 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-20 00:49:33 +08:00
|
|
|
static int raid_preresume(struct dm_target *ti)
|
|
|
|
{
|
2016-06-13 23:55:14 +08:00
|
|
|
int r;
|
2016-05-20 00:49:33 +08:00
|
|
|
struct raid_set *rs = ti->private;
|
|
|
|
struct mddev *mddev = &rs->md;
|
|
|
|
|
2017-12-14 00:13:18 +08:00
|
|
|
/* This is a resume after a suspend of the set -> it's already started. */
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(RT_FLAG_RS_PRERESUMED, &rs->runtime_flags))
|
2016-05-20 00:49:33 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The superblocks need to be updated on disk if the
|
2016-06-15 03:23:13 +08:00
|
|
|
* array is new or new devices got added (thus zeroed
|
|
|
|
* out by userspace) or __load_dirty_region_bitmap
|
|
|
|
* will overwrite them in core with old data or fail.
|
2016-05-20 00:49:33 +08:00
|
|
|
*/
|
2016-06-15 03:23:13 +08:00
|
|
|
if (test_bit(RT_FLAG_UPDATE_SBS, &rs->runtime_flags))
|
|
|
|
rs_update_sbs(rs);
|
2016-05-20 00:49:33 +08:00
|
|
|
|
|
|
|
/* Load the bitmap from disk unless raid0 */
|
2016-06-13 23:55:14 +08:00
|
|
|
r = __load_dirty_region_bitmap(rs);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
2019-10-01 23:47:53 +08:00
|
|
|
/* We are extending the raid set size, adjust mddev/md_rdev sizes and set capacity. */
|
|
|
|
if (test_bit(RT_FLAG_RS_GROW, &rs->runtime_flags)) {
|
|
|
|
mddev->array_sectors = rs->array_sectors;
|
|
|
|
mddev->dev_sectors = rs->dev_sectors;
|
|
|
|
rs_set_rdev_sectors(rs);
|
|
|
|
rs_set_capacity(rs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Resize bitmap to adjust to changed region size (aka MD bitmap chunksize) or grown device size */
|
|
|
|
if (test_bit(RT_FLAG_RS_BITMAP_LOADED, &rs->runtime_flags) && mddev->bitmap &&
|
|
|
|
(test_bit(RT_FLAG_RS_GROW, &rs->runtime_flags) ||
|
|
|
|
(rs->requested_bitmap_chunk_sectors &&
|
|
|
|
mddev->bitmap_info.chunksize != to_bytes(rs->requested_bitmap_chunk_sectors)))) {
|
|
|
|
int chunksize = to_bytes(rs->requested_bitmap_chunk_sectors) ?: mddev->bitmap_info.chunksize;
|
|
|
|
|
|
|
|
r = md_bitmap_resize(mddev->bitmap, mddev->dev_sectors, chunksize, 0);
|
2016-06-14 07:46:03 +08:00
|
|
|
if (r)
|
|
|
|
DMERR("Failed to resize bitmap");
|
|
|
|
}
|
|
|
|
|
2016-06-13 23:55:14 +08:00
|
|
|
/* Check for any resize/reshape on @rs and adjust/initiate */
|
|
|
|
/* Be prepared for mddev_resume() in raid_resume() */
|
|
|
|
set_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
|
|
|
|
if (mddev->recovery_cp && mddev->recovery_cp < MaxSector) {
|
2019-10-01 23:47:53 +08:00
|
|
|
set_bit(MD_RECOVERY_REQUESTED, &mddev->recovery);
|
2016-06-13 23:55:14 +08:00
|
|
|
mddev->resync_min = mddev->recovery_cp;
|
2019-10-01 23:47:53 +08:00
|
|
|
if (test_bit(RT_FLAG_RS_GROW, &rs->runtime_flags))
|
|
|
|
mddev->resync_max_sectors = mddev->dev_sectors;
|
2016-06-13 23:55:14 +08:00
|
|
|
}
|
|
|
|
|
2016-06-25 08:42:54 +08:00
|
|
|
/* Check for any reshape request unless new raid set */
|
2017-12-02 08:03:52 +08:00
|
|
|
if (test_bit(RT_FLAG_RESHAPE_RS, &rs->runtime_flags)) {
|
2016-06-13 23:55:14 +08:00
|
|
|
/* Initiate a reshape. */
|
2017-12-02 08:03:51 +08:00
|
|
|
rs_set_rdev_sectors(rs);
|
2016-06-13 23:55:14 +08:00
|
|
|
mddev_lock_nointr(mddev);
|
|
|
|
r = rs_start_reshape(rs);
|
|
|
|
mddev_unlock(mddev);
|
|
|
|
if (r)
|
|
|
|
DMWARN("Failed to check/start reshape, continuing without change");
|
|
|
|
r = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
2016-05-20 00:49:33 +08:00
|
|
|
}
|
|
|
|
|
2013-05-09 06:57:13 +08:00
|
|
|
static void raid_resume(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct raid_set *rs = ti->private;
|
2016-05-20 00:49:33 +08:00
|
|
|
struct mddev *mddev = &rs->md;
|
2013-05-09 06:57:13 +08:00
|
|
|
|
2016-06-03 00:27:46 +08:00
|
|
|
if (test_and_set_bit(RT_FLAG_RS_RESUMED, &rs->runtime_flags)) {
|
2016-05-20 00:49:33 +08:00
|
|
|
/*
|
|
|
|
* A secondary resume while the device is active.
|
|
|
|
* Take this opportunity to check whether any failed
|
|
|
|
* devices are reachable again.
|
|
|
|
*/
|
|
|
|
attempt_restore_of_faulty_devices(rs);
|
2016-08-10 08:45:59 +08:00
|
|
|
}
|
2012-01-28 04:53:53 +08:00
|
|
|
|
2017-10-19 09:17:16 +08:00
|
|
|
if (test_and_clear_bit(RT_FLAG_RS_SUSPENDED, &rs->runtime_flags)) {
|
2017-12-14 00:13:18 +08:00
|
|
|
/* Only reduce raid set size before running a disk removing reshape. */
|
|
|
|
if (mddev->delta_disks < 0)
|
|
|
|
rs_set_capacity(rs);
|
|
|
|
|
2017-10-19 09:17:16 +08:00
|
|
|
mddev_lock_nointr(mddev);
|
2017-12-14 00:13:18 +08:00
|
|
|
clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
|
2017-12-02 08:03:56 +08:00
|
|
|
mddev->ro = 0;
|
|
|
|
mddev->in_sync = 0;
|
2016-08-10 08:45:59 +08:00
|
|
|
mddev_resume(mddev);
|
2017-10-19 09:17:16 +08:00
|
|
|
mddev_unlock(mddev);
|
|
|
|
}
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct target_type raid_target = {
|
|
|
|
.name = "raid",
|
2019-12-20 00:58:46 +08:00
|
|
|
.version = {1, 15, 1},
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
.module = THIS_MODULE,
|
|
|
|
.ctr = raid_ctr,
|
|
|
|
.dtr = raid_dtr,
|
|
|
|
.map = raid_map,
|
|
|
|
.status = raid_status,
|
2013-04-24 09:42:43 +08:00
|
|
|
.message = raid_message,
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
.iterate_devices = raid_iterate_devices,
|
|
|
|
.io_hints = raid_io_hints,
|
|
|
|
.postsuspend = raid_postsuspend,
|
2016-05-20 00:49:33 +08:00
|
|
|
.preresume = raid_preresume,
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
.resume = raid_resume,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init dm_raid_init(void)
|
|
|
|
{
|
2013-02-21 10:28:10 +08:00
|
|
|
DMINFO("Loading target version %u.%u.%u",
|
|
|
|
raid_target.version[0],
|
|
|
|
raid_target.version[1],
|
|
|
|
raid_target.version[2]);
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
return dm_register_target(&raid_target);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit dm_raid_exit(void)
|
|
|
|
{
|
|
|
|
dm_unregister_target(&raid_target);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(dm_raid_init);
|
|
|
|
module_exit(dm_raid_exit);
|
|
|
|
|
2014-09-24 23:47:19 +08:00
|
|
|
module_param(devices_handle_discard_safely, bool, 0644);
|
|
|
|
MODULE_PARM_DESC(devices_handle_discard_safely,
|
|
|
|
"Set to Y if all devices in each array reliably return zeroes on reads from discarded regions");
|
|
|
|
|
2016-06-03 00:02:19 +08:00
|
|
|
MODULE_DESCRIPTION(DM_NAME " raid0/1/10/4/5/6 target");
|
|
|
|
MODULE_ALIAS("dm-raid0");
|
2012-08-01 10:44:26 +08:00
|
|
|
MODULE_ALIAS("dm-raid1");
|
|
|
|
MODULE_ALIAS("dm-raid10");
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
MODULE_ALIAS("dm-raid4");
|
|
|
|
MODULE_ALIAS("dm-raid5");
|
|
|
|
MODULE_ALIAS("dm-raid6");
|
|
|
|
MODULE_AUTHOR("Neil Brown <dm-devel@redhat.com>");
|
2016-05-20 00:49:34 +08:00
|
|
|
MODULE_AUTHOR("Heinz Mauelshagen <dm-devel@redhat.com>");
|
dm: raid456 basic support
This patch is the skeleton for the DM target that will be
the bridge from DM to MD (initially RAID456 and later RAID1). It
provides a way to use device-mapper interfaces to the MD RAID456
drivers.
As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:
1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".
Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (again, raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <value>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.
Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).
Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Cc: linux-raid@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2011-01-14 04:00:02 +08:00
|
|
|
MODULE_LICENSE("GPL");
|