1LVMRAID(7) LVMRAID(7)
2
6 lvmraid — LVM RAID
7
10 lvm(8) RAID is a way to create a Logical Volume (LV) that uses multiple
11 physical devices to improve performance or tolerate device failures.
12 In LVM, the physical devices are Physical Volumes (PVs) in a single
13 Volume Group (VG).
14 How LV data blocks are placed onto PVs is determined by the RAID level.
16 RAID levels are commonly referred to as 'raid' followed by a number,
17 e.g. raid1, raid5 or raid6. Selecting a RAID level involves making
18 tradeoffs among: physical device requirements, fault tolerance, and
19 performance. A description of the RAID levels can be found at
20 www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
21 LVM RAID uses both Device Mapper (DM) and Multiple Device (MD) drivers
23 from the Linux kernel. DM is used to create and manage visible LVM de‐
24 vices, and MD is used to place data on physical devices.
25 LVM creates hidden LVs (dm devices) layered between the visible LV and
27 physical devices. LVs in the middle layers are called sub LVs. For
28 LVM raid, a sub LV pair to store data and metadata (raid superblock and
29 write intent bitmap) is created per raid image/leg (see lvs command ex‐
30 amples below).
31
34 To create a RAID LV, use lvcreate and specify an LV type. The LV type
35 corresponds to a RAID level. The basic RAID levels that can be used
36 are: raid0, raid1, raid4, raid5, raid6, raid10.
37 lvcreate --type RaidLevel [OPTIONS] --name Name --size Size VG [PVs]
39 To display the LV type of an existing LV, run:
41 lvs -o name,segtype LV
43 (The LV type is also referred to as "segment type" or "segtype".)
45 LVs can be created with the following types:
47 raid0
50 Also called striping, raid0 spreads LV data across multiple devices in
53 units of stripe size. This is used to increase performance. LV data
54 will be lost if any of the devices fail.
55 lvcreate --type raid0 [--stripes Number --stripesize Size] VG [PVs]
57 --stripes specifies the number of devices to spread the LV across.
60 --stripesize specifies the size of each stripe in kilobytes. This is
63 the amount of data that is written to one device before moving
64 to the next.
65 PVs specifies the devices to use. If not specified, lvm will choose
67 Number devices, one for each stripe based on the number of PVs avail‐
68 able or supplied.
69 raid1
72 Also called mirroring, raid1 uses multiple devices to duplicate LV
75 data. The LV data remains available if all but one of the devices
76 fail. The minimum number of devices (i.e. sub LV pairs) required is 2.
77 lvcreate --type raid1 [--mirrors Number] VG [PVs]
79 --mirrors specifies the number of mirror images in addition to the
82 original LV image, e.g. --mirrors 1 means there are two images
83 of the data, the original and one mirror image.
84 PVs specifies the devices to use. If not specified, lvm will choose
86 Number devices, one for each image.
87 raid4
90 raid4 is a form of striping that uses an extra, first device dedicated
93 to storing parity blocks. The LV data remains available if one device
94 fails. The parity is used to recalculate data that is lost from a sin‐
95 gle device. The minimum number of devices required is 3.
96 lvcreate --type raid4 [--stripes Number --stripesize Size] VG [PVs]
98 --stripes specifies the number of devices to use for LV data. This
101 does not include the extra device lvm adds for storing parity
102 blocks. A raid4 LV with Number stripes requires Number+1 de‐
103 vices. Number must be 2 or more.
104 --stripesize specifies the size of each stripe in kilobytes. This is
107 the amount of data that is written to one device before moving
108 to the next.
109 PVs specifies the devices to use. If not specified, lvm will choose
111 Number+1 separate devices.
112 raid4 is called non-rotating parity because the parity blocks are al‐
114 ways stored on the same device.
115 raid5
118 raid5 is a form of striping that uses an extra device for storing par‐
121 ity blocks. LV data and parity blocks are stored on each device, typi‐
122 cally in a rotating pattern for performance reasons. The LV data re‐
123 mains available if one device fails. The parity is used to recalculate
124 data that is lost from a single device. The minimum number of devices
125 required is 3 (unless converting from 2 legged raid1 to reshape to more
126 stripes; see reshaping).
127 lvcreate --type raid5 [--stripes Number --stripesize Size] VG [PVs]
129 --stripes specifies the number of devices to use for LV data. This
132 does not include the extra device lvm adds for storing parity
133 blocks. A raid5 LV with Number stripes requires Number+1 de‐
134 vices. Number must be 2 or more.
135 --stripesize specifies the size of each stripe in kilobytes. This is
138 the amount of data that is written to one device before moving
139 to the next.
140 PVs specifies the devices to use. If not specified, lvm will choose
142 Number+1 separate devices.
143 raid5 is called rotating parity because the parity blocks are placed on
145 different devices in a round-robin sequence. There are variations of
146 raid5 with different algorithms for placing the parity blocks. The de‐
147 fault variant is raid5_ls (raid5 left symmetric, which is a rotating
148 parity 0 with data restart.) See RAID5 variants below.
149 raid6
152 raid6 is a form of striping like raid5, but uses two extra devices for
155 parity blocks. LV data and parity blocks are stored on each device,
156 typically in a rotating pattern for perfomramce reasons. The LV data
157 remains available if up to two devices fail. The parity is used to re‐
158 calculate data that is lost from one or two devices. The minimum num‐
159 ber of devices required is 5.
160 lvcreate --type raid6 [--stripes Number --stripesize Size] VG [PVs]
162 --stripes specifies the number of devices to use for LV data. This
165 does not include the extra two devices lvm adds for storing par‐
166 ity blocks. A raid6 LV with Number stripes requires Number+2
167 devices. Number must be 3 or more.
168 --stripesize specifies the size of each stripe in kilobytes. This is
171 the amount of data that is written to one device before moving
172 to the next.
173 PVs specifies the devices to use. If not specified, lvm will choose
175 Number+2 separate devices.
176 Like raid5, there are variations of raid6 with different algorithms for
178 placing the parity blocks. The default variant is raid6_zr (raid6 zero
179 restart, aka left symmetric, which is a rotating parity 0 with data
180 restart.) See RAID6 variants below.
181 raid10
184 raid10 is a combination of raid1 and raid0, striping data across mir‐
187 rored devices. LV data remains available if one or more devices re‐
188 mains in each mirror set. The minimum number of devices required is 4.
189 lvcreate --type raid10
191 [--mirrors NumberMirrors]
192 [--stripes NumberStripes --stripesize Size]
193 VG [PVs]
194 --mirrors specifies the number of mirror images within each stripe.
197 e.g. --mirrors 1 means there are two images of the data, the
198 original and one mirror image.
199 --stripes specifies the total number of devices to use in all raid1 im‐
202 ages (not the number of raid1 devices to spread the LV across,
203 even though that is the effective result). The number of de‐
204 vices in each raid1 mirror will be NumberStripes/(NumberMir‐
205 rors+1), e.g. mirrors 1 and stripes 4 will stripe data across
206 two raid1 mirrors, where each mirror is devices.
207 --stripesize specifies the size of each stripe in kilobytes. This is
210 the amount of data that is written to one device before moving
211 to the next.
212 PVs specifies the devices to use. If not specified, lvm will choose
214 the necessary devices. Devices are used to create mirrors in the order
215 listed, e.g. for mirrors 1, stripes 2, listing PV1 PV2 PV3 PV4 results
216 in mirrors PV1/PV2 and PV3/PV4.
217 RAID10 is not mirroring on top of stripes, which would be RAID01, which
219 is less tolerant of device failures.
220
224 Synchronization is the process that makes all the devices in a RAID LV
225 consistent with each other.
226 In a RAID1 LV, all mirror images should have the same data. When a new
228 mirror image is added, or a mirror image is missing data, then images
229 need to be synchronized. Data blocks are copied from an existing image
230 to a new or outdated image to make them match.
231 In a RAID 4/5/6 LV, parity blocks and data blocks should match based on
233 the parity calculation. When the devices in a RAID LV change, the data
234 and parity blocks can become inconsistent and need to be synchronized.
235 Correct blocks are read, parity is calculated, and recalculated blocks
236 are written.
237 The RAID implementation keeps track of which parts of a RAID LV are
239 synchronized. When a RAID LV is first created and activated the first
240 synchronization is called initialization. A pointer stored in the raid
241 metadata keeps track of the initialization process thus allowing it to
242 be restarted after a deactivation of the RaidLV or a crash. Any writes
243 to the RaidLV dirties the respective region of the write intent bitmap
244 which allow for fast recovery of the regions after a crash. Without
245 this, the entire LV would need to be synchronized every time it was ac‐
246 tivated.
247 Automatic synchronization happens when a RAID LV is activated, but it
249 is usually partial because the bitmaps reduce the areas that are
250 checked. A full sync becomes necessary when devices in the RAID LV are
251 replaced.
252 The synchronization status of a RAID LV is reported by the following
254 command, where "Cpy%Sync" = "100%" means sync is complete:
255 lvs -a -o name,sync_percent
257 Scrubbing
261 Scrubbing is a full scan of the RAID LV requested by a user. Scrubbing
262 can find problems that are missed by partial synchronization.
263 Scrubbing assumes that RAID metadata and bitmaps may be inaccurate, so
265 it verifies all RAID metadata, LV data, and parity blocks. Scrubbing
266 can find inconsistencies caused by hardware errors or degradation.
267 These kinds of problems may be undetected by automatic synchronization
268 which excludes areas outside of the RAID write-intent bitmap.
269 The command to scrub a RAID LV can operate in two different modes:
271 lvchange --syncaction check|repair LV
273 check Check mode is read-only and only detects inconsistent areas in
276 the RAID LV, it does not correct them.
277 repair Repair mode checks and writes corrected blocks to synchronize
280 any inconsistent areas.
281 Scrubbing can consume a lot of bandwidth and slow down application I/O
284 on the RAID LV. To control the I/O rate used for scrubbing, use:
285 --maxrecoveryrate Size[k|UNIT]
288 Sets the maximum recovery rate for a RAID LV. Size is specified
289 as an amount per second for each device in the array. If no
290 suffix is given, then KiB/sec/device is used. Setting the re‐
291 covery rate to 0 means it will be unbounded.
292 --minrecoveryrate Size[k|UNIT]
295 Sets the minimum recovery rate for a RAID LV. Size is specified
296 as an amount per second for each device in the array. If no
297 suffix is given, then KiB/sec/device is used. Setting the re‐
298 covery rate to 0 means it will be unbounded.
299 To display the current scrubbing in progress on an LV, including the
302 syncaction mode and percent complete, run:
303 lvs -a -o name,raid_sync_action,sync_percent
305 After scrubbing is complete, to display the number of inconsistent
307 blocks found, run:
308 lvs -o name,raid_mismatch_count
310 Also, if mismatches were found, the lvs attr field will display the
312 letter "m" (mismatch) in the 9th position, e.g.
313 # lvs -o name,vgname,segtype,attr vg/lv
315 LV VG Type Attr
316 lv vg raid1 Rwi-a-r-m-
317 Scrubbing Limitations
321 The check mode can only report the number of inconsistent blocks, it
322 cannot report which blocks are inconsistent. This makes it impossible
323 to know which device has errors, or if the errors affect file system
324 data, metadata or nothing at all.
325 The repair mode can make the RAID LV data consistent, but it does not
327 know which data is correct. The result may be consistent but incorrect
328 data. When two different blocks of data must be made consistent, it
329 chooses the block from the device that would be used during RAID in‐
330 tialization. However, if the PV holding corrupt data is known,
331 lvchange --rebuild can be used in place of scrubbing to reconstruct the
332 data on the bad device.
333 Future developments might include:
335 Allowing a user to choose the correct version of data during repair.
337 Using a majority of devices to determine the correct version of data to
339 use in a 3-way RAID1 or RAID6 LV.
340 Using a checksumming device to pin-point when and where an error oc‐
342 curs, allowing it to be rewritten.
343
347 An LV is often a combination of other hidden LVs called SubLVs. The
348 SubLVs either use physical devices, or are built from other SubLVs
349 themselves. SubLVs hold LV data blocks, RAID parity blocks, and RAID
350 metadata. SubLVs are generally hidden, so the lvs -a option is re‐
351 quired to display them:
352 lvs -a -o name,segtype,devices
354 SubLV names begin with the visible LV name, and have an automatic suf‐
356 fix indicating its role:
357 • SubLVs holding LV data or parity blocks have the suffix _rimage_#.
360 These SubLVs are sometimes referred to as DataLVs.
361 • SubLVs holding RAID metadata have the suffix _rmeta_#. RAID meta‐
364 data includes superblock information, RAID type, bitmap, and device
365 health information. These SubLVs are sometimes referred to as Met‐
366 aLVs.
367 SubLVs are an internal implementation detail of LVM. The way they are
370 used, constructed and named may change.
371 The following examples show the SubLV arrangement for each of the basic
373 RAID LV types, using the fewest number of devices allowed for each.
374 Examples
377 raid0
378 Each rimage SubLV holds a portion of LV data. No parity is used. No
379 RAID metadata is used.
380 # lvcreate --type raid0 --stripes 2 --name lvr0 ...
382 # lvs -a -o name,segtype,devices
384 lvr0 raid0 lvr0_rimage_0(0),lvr0_rimage_1(0)
385 [lvr0_rimage_0] linear /dev/sda(...)
386 [lvr0_rimage_1] linear /dev/sdb(...)
387 raid1
389 Each rimage SubLV holds a complete copy of LV data. No parity is used.
390 Each rmeta SubLV holds RAID metadata.
391 # lvcreate --type raid1 --mirrors 1 --name lvr1 ...
393 # lvs -a -o name,segtype,devices
395 lvr1 raid1 lvr1_rimage_0(0),lvr1_rimage_1(0)
396 [lvr1_rimage_0] linear /dev/sda(...)
397 [lvr1_rimage_1] linear /dev/sdb(...)
398 [lvr1_rmeta_0] linear /dev/sda(...)
399 [lvr1_rmeta_1] linear /dev/sdb(...)
400 raid4
402 At least three rimage SubLVs each hold a portion of LV data and one
403 rimage SubLV holds parity. Each rmeta SubLV holds RAID metadata.
404 # lvcreate --type raid4 --stripes 2 --name lvr4 ...
406 # lvs -a -o name,segtype,devices
408 lvr4 raid4 lvr4_rimage_0(0),\
409 lvr4_rimage_1(0),\
410 lvr4_rimage_2(0)
411 [lvr4_rimage_0] linear /dev/sda(...)
412 [lvr4_rimage_1] linear /dev/sdb(...)
413 [lvr4_rimage_2] linear /dev/sdc(...)
414 [lvr4_rmeta_0] linear /dev/sda(...)
415 [lvr4_rmeta_1] linear /dev/sdb(...)
416 [lvr4_rmeta_2] linear /dev/sdc(...)
417 raid5
419 At least three rimage SubLVs each typcially hold a portion of LV data
420 and parity (see section on raid5) Each rmeta SubLV holds RAID metadata.
421 # lvcreate --type raid5 --stripes 2 --name lvr5 ...
423 # lvs -a -o name,segtype,devices
425 lvr5 raid5 lvr5_rimage_0(0),\
426 lvr5_rimage_1(0),\
427 lvr5_rimage_2(0)
428 [lvr5_rimage_0] linear /dev/sda(...)
429 [lvr5_rimage_1] linear /dev/sdb(...)
430 [lvr5_rimage_2] linear /dev/sdc(...)
431 [lvr5_rmeta_0] linear /dev/sda(...)
432 [lvr5_rmeta_1] linear /dev/sdb(...)
433 [lvr5_rmeta_2] linear /dev/sdc(...)
434 raid6
436 At least five rimage SubLVs each typically hold a portion of LV data
437 and parity. (see section on raid6) Each rmeta SubLV holds RAID meta‐
438 data.
439 # lvcreate --type raid6 --stripes 3 --name lvr6
441 # lvs -a -o name,segtype,devices
443 lvr6 raid6 lvr6_rimage_0(0),\
444 lvr6_rimage_1(0),\
445 lvr6_rimage_2(0),\
446 lvr6_rimage_3(0),\
447 lvr6_rimage_4(0),\
448 lvr6_rimage_5(0)
449 [lvr6_rimage_0] linear /dev/sda(...)
450 [lvr6_rimage_1] linear /dev/sdb(...)
451 [lvr6_rimage_2] linear /dev/sdc(...)
452 [lvr6_rimage_3] linear /dev/sdd(...)
453 [lvr6_rimage_4] linear /dev/sde(...)
454 [lvr6_rimage_5] linear /dev/sdf(...)
455 [lvr6_rmeta_0] linear /dev/sda(...)
456 [lvr6_rmeta_1] linear /dev/sdb(...)
457 [lvr6_rmeta_2] linear /dev/sdc(...)
458 [lvr6_rmeta_3] linear /dev/sdd(...)
459 [lvr6_rmeta_4] linear /dev/sde(...)
460 [lvr6_rmeta_5] linear /dev/sdf(...)
461 raid10
463 At least four rimage SubLVs each hold a portion of LV data. No parity
464 is used. Each rmeta SubLV holds RAID metadata.
465 # lvcreate --type raid10 --stripes 2 --mirrors 1 --name lvr10
467 # lvs -a -o name,segtype,devices
469 lvr10 raid10 lvr10_rimage_0(0),\
470 lvr10_rimage_1(0),\
471 lvr10_rimage_2(0),\
472 lvr10_rimage_3(0)
473 [lvr10_rimage_0] linear /dev/sda(...)
474 [lvr10_rimage_1] linear /dev/sdb(...)
475 [lvr10_rimage_2] linear /dev/sdc(...)
476 [lvr10_rimage_3] linear /dev/sdd(...)
477 [lvr10_rmeta_0] linear /dev/sda(...)
478 [lvr10_rmeta_1] linear /dev/sdb(...)
479 [lvr10_rmeta_2] linear /dev/sdc(...)
480 [lvr10_rmeta_3] linear /dev/sdd(...)
481
485 Physical devices in a RAID LV can fail or be lost for multiple reasons.
486 A device could be disconnected, permanently failed, or temporarily dis‐
487 connected. The purpose of RAID LVs (levels 1 and higher) is to con‐
488 tinue operating in a degraded mode, without losing LV data, even after
489 a device fails. The number of devices that can fail without the loss
490 of LV data depends on the RAID level:
491 • RAID0 (striped) LVs cannot tolerate losing any devices. LV data
494 will be lost if any devices fail.
495 • RAID1 LVs can tolerate losing all but one device without LV data
498 loss.
499 • RAID4 and RAID5 LVs can tolerate losing one device without LV data
502 loss.
503 • RAID6 LVs can tolerate losing two devices without LV data loss.
506 • RAID10 is variable, and depends on which devices are lost. It
509 stripes across multiple mirror groups with raid1 layout thus it can
510 tolerate losing all but one device in each of these groups without
511 LV data loss.
512 If a RAID LV is missing devices, or has other device-related problems,
515 lvs reports this in the health_status (and attr) fields:
516 lvs -o name,lv_health_status
518 partial
520 Devices are missing from the LV. This is also indicated by the letter
521 "p" (partial) in the 9th position of the lvs attr field.
522 refresh needed
524 A device was temporarily missing but has returned. The LV needs to be
525 refreshed to use the device again (which will usually require partial
526 synchronization). This is also indicated by the letter "r" (refresh
527 needed) in the 9th position of the lvs attr field. See Refreshing an
528 LV. This could also indicate a problem with the device, in which case
529 it should be be replaced, see Replacing Devices.
530 mismatches exist
532 See Scrubbing.
533 Most commands will also print a warning if a device is missing, e.g.
535 WARNING: Device for PV uItL3Z-wBME-DQy0-... not found or rejected ...
536 This warning will go away if the device returns or is removed from the
538 VG (see vgreduce --removemissing).
539 Activating an LV with missing devices
543 A RAID LV that is missing devices may be activated or not, depending on
544 the "activation mode" used in lvchange:
545 lvchange -ay --activationmode complete|degraded|partial LV
547 complete
549 The LV is only activated if all devices are present.
550 degraded
552 The LV is activated with missing devices if the RAID level can tolerate
553 the number of missing devices without LV data loss.
554 partial
556 The LV is always activated, even if portions of the LV data are missing
557 because of the missing device(s). This should only be used to perform
558 extreme recovery or repair operations.
559 lvm.conf(5) activation/activation_mode
561 controls the activation mode when not specified by the command.
562 The default value is printed by:
564 lvmconfig --type default activation/activation_mode
565 Replacing Devices
568 Devices in a RAID LV can be replaced by other devices in the VG. When
569 replacing devices that are no longer visible on the system, use lvcon‐
570 vert --repair. When replacing devices that are still visible, use lv‐
571 convert --replace. The repair command will attempt to restore the same
572 number of data LVs that were previously in the LV. The replace option
573 can be repeated to replace multiple PVs. Replacement devices can be
574 optionally listed with either option.
575 lvconvert --repair LV [NewPVs]
577 lvconvert --replace OldPV LV [NewPV]
579 lvconvert --replace OldPV1 --replace OldPV2 LV [NewPVs]
581 New devices require synchronization with existing devices, see Synchro‐
583 nization.
584 Refreshing an LV
587 Refreshing a RAID LV clears any transient device failures (device was
588 temporarily disconnected) and returns the LV to its fully redundant
589 mode. Restoring a device will usually require at least partial syn‐
590 chronization (see Synchronization). Failure to clear a transient fail‐
591 ure results in the RAID LV operating in degraded mode until it is reac‐
592 tivated. Use the lvchange command to refresh an LV:
593 lvchange --refresh LV
595 # lvs -o name,vgname,segtype,attr,size vg
597 LV VG Type Attr LSize
598 lv vg raid1 Rwi-a-r-r- 100.00g
599 # lvchange --refresh vg/lv
601 # lvs -o name,vgname,segtype,attr,size vg
603 LV VG Type Attr LSize
604 lv vg raid1 Rwi-a-r--- 100.00g
605 Automatic repair
608 If a device in a RAID LV fails, device-mapper in the kernel notifies
609 the dmeventd(8) monitoring process (see Monitoring). dmeventd can be
610 configured to automatically respond using:
611 lvm.conf(5) activation/raid_fault_policy
613 Possible settings are:
615 warn
617 A warning is added to the system log indicating that a device has
618 failed in the RAID LV. It is left to the user to repair the LV, e.g.
619 replace failed devices.
620 allocate
622 dmeventd automatically attempts to repair the LV using spare devices in
623 the VG. Note that even a transient failure is treated as a permanent
624 failure under this setting. A new device is allocated and full syn‐
625 chronization is started.
626 The specific command run by dmeventd to warn or repair is:
628 lvconvert --repair --use-policies LV
629 Corrupted Data
633 Data on a device can be corrupted due to hardware errors without the
634 device ever being disconnected or there being any fault in the soft‐
635 ware. This should be rare, and can be detected (see Scrubbing).
636 Rebuild specific PVs
640 If specific PVs in a RAID LV are known to have corrupt data, the data
641 on those PVs can be reconstructed with:
642 lvchange --rebuild PV LV
644 The rebuild option can be repeated with different PVs to replace the
646 data on multiple PVs.
647
651 When a RAID LV is activated the dmeventd(8) process is started to moni‐
652 tor the health of the LV. Various events detected in the kernel can
653 cause a notification to be sent from device-mapper to the monitoring
654 process, including device failures and synchronization completion (e.g.
655 for initialization or scrubbing).
656 The LVM configuration file contains options that affect how the moni‐
658 toring process will respond to failure events (e.g. raid_fault_policy).
659 It is possible to turn on and off monitoring with lvchange, but it is
660 not recommended to turn this off unless you have a thorough knowledge
661 of the consequences.
662
666 There are a number of options in the LVM configuration file that affect
667 the behavior of RAID LVs. The tunable options are listed below. A de‐
668 tailed description of each can be found in the LVM configuration file
669 itself.
670 mirror_segtype_default
671 raid10_segtype_default
672 raid_region_size
673 raid_fault_policy
674 activation_mode
675
679 The device mapper integrity target can be used in combination with RAID
680 levels 1,4,5,6,10 to detect and correct data corruption in RAID images.
681 A dm-integrity layer is placed above each RAID image, and an extra sub
682 LV is created to hold integrity metadata (data checksums) for each RAID
683 image. When data is read from an image, integrity checksums are used
684 to detect corruption. If detected, dm-raid reads the data from another
685 (good) image to return to the caller. dm-raid will also automatically
686 write the good data back to the image with bad data to correct the cor‐
687 ruption.
688 When creating a RAID LV with integrity, or adding integrity, space is
690 required for integrity metadata. Every 500MB of LV data requires an
691 additional 4MB to be allocated for integrity metadata, for each RAID
692 image.
693 Create a RAID LV with integrity:
695 lvcreate --type raidN --raidintegrity y
697 Add integrity to an existing RAID LV:
699 lvconvert --raidintegrity y LV
701 Remove integrity from a RAID LV:
703 lvconvert --raidintegrity n LV
705 Integrity options
708 --raidintegritymode journal|bitmap
709 Use a journal (default) or bitmap for keeping integrity checksums con‐
711 sistent in case of a crash. The bitmap areas are recalculated after a
712 crash, so corruption in those areas would not be detected. A journal
713 does not have this problem. The journal mode doubles writes to stor‐
714 age, but can improve performance for scattered writes packed into a
715 single journal write. bitmap mode can in theory achieve full write
716 throughput of the device, but would not benefit from the potential
717 scattered write optimization.
718 --raidintegrityblocksize 512|1024|2048|4096
720 The block size to use for dm-integrity on raid images. The integrity
722 block size should usually match the device logical block size, or the
723 file system sector/block sizes. It may be less than the file system
724 sector/block size, but not less than the device logical block size.
725 Possible values: 512, 1024, 2048, 4096.
726 Integrity initialization
729 When integrity is added to an LV, the kernel needs to initialize the
730 integrity metadata (checksums) for all blocks in the LV. The data cor‐
731 ruption checking performed by dm-integrity will only operate on areas
732 of the LV that are already initialized. The progress of integrity ini‐
733 tialization is reported by the "syncpercent" LV reporting field (and
734 under the Cpy%Sync lvs column.)
735 Integrity limitations
738 To work around some limitations, it is possible to remove integrity
739 from the LV, make the change, then add integrity again. (Integrity
740 metadata would need to initialized when added again.)
741 LVM must be able to allocate the integrity metadata sub LV on a single
743 PV that is already in use by the associated RAID image. This can poten‐
744 tially cause a problem during lvextend if the original PV holding the
745 image and integrity metadata is full. To work around this limitation,
746 remove integrity, extend the LV, and add integrity again.
747 Additional RAID images can be added to raid1 LVs, but not to other raid
749 levels.
750 A raid1 LV with integrity cannot be converted to linear (remove integ‐
752 rity to do this.)
753 RAID LVs with integrity cannot yet be used as sub LVs with other LV
755 types.
756 The following are not yet permitted on RAID LVs with integrity: lvre‐
758 duce, pvmove, snapshots, splitmirror, raid syncaction commands, raid
759 rebuild.
760
763 A RAID1 LV can be tuned so that certain devices are avoided for reading
764 while all devices are still written to.
765 lvchange --[raid]writemostly PV[:y|n|t] LV
767 The specified device will be marked as "write mostly", which means that
769 reading from this device will be avoided, and other devices will be
770 preferred for reading (unless no other devices are available.) This
771 minimizes the I/O to the specified device.
772 If the PV name has no suffix, the write mostly attribute is set. If
774 the PV name has the suffix :n, the write mostly attribute is cleared,
775 and the suffix :t toggles the current setting.
776 The write mostly option can be repeated on the command line to change
778 multiple devices at once.
779 To report the current write mostly setting, the lvs attr field will
781 show the letter "w" in the 9th position when write mostly is set:
782 lvs -a -o name,attr
784 When a device is marked write mostly, the maximum number of outstanding
786 writes to that device can be configured. Once the maximum is reached,
787 further writes become synchronous. When synchronous, a write to the LV
788 will not complete until writes to all the mirror images are complete.
789 lvchange --[raid]writebehind Number LV
791 To report the current write behind setting, run:
793 lvs -o name,raid_write_behind
795 When write behind is not configured, or set to 0, all LV writes are
797 synchronous.
798
802 RAID takeover is converting a RAID LV from one RAID level to another,
803 e.g. raid5 to raid6. Changing the RAID level is usually done to in‐
804 crease or decrease resilience to device failures or to restripe LVs.
805 This is done using lvconvert and specifying the new RAID level as the
806 LV type:
807 lvconvert --type RaidLevel LV [PVs]
809 The most common and recommended RAID takeover conversions are:
811 linear to raid1
814 Linear is a single image of LV data, and converting it to raid1
815 adds a mirror image which is a direct copy of the original lin‐
816 ear image.
817 striped/raid0 to raid4/5/6
820 Adding parity devices to a striped volume results in raid4/5/6.
821 Unnatural conversions that are not recommended include converting be‐
824 tween striped and non-striped types. This is because file systems of‐
825 ten optimize I/O patterns based on device striping values. If those
826 values change, it can decrease performance.
827 Converting to a higher RAID level requires allocating new SubLVs to
829 hold RAID metadata, and new SubLVs to hold parity blocks for LV data.
830 Converting to a lower RAID level removes the SubLVs that are no longer
831 needed.
832 Conversion often requires full synchronization of the RAID LV (see Syn‐
834 chronization). Converting to RAID1 requires copying all LV data blocks
835 to N new images on new devices. Converting to a parity RAID level re‐
836 quires reading all LV data blocks, calculating parity, and writing the
837 new parity blocks. Synchronization can take a long time depending on
838 the throughpout of the devices used and the size of the RaidLV. It can
839 degrade performance (rate controls also apply to conversion; see --min‐
840 recoveryrate and --maxrecoveryrate.)
841 Warning: though it is possible to create striped LVs with up to 128
843 stripes, a maximum of 64 stripes can be converted to raid0, 63 to
844 raid4/5 and 62 to raid6 because of the added parity SubLVs. A striped
845 LV with a maximum of 32 stripes can be converted to raid10.
846 The following takeover conversions are currently possible:
849 • between striped and raid0.
851 • between linear and raid1.
853 • between mirror and raid1.
855 • between raid1 with two images and raid4/5.
857 • between striped/raid0 and raid4.
859 • between striped/raid0 and raid5.
861 • between striped/raid0 and raid6.
863 • between raid4 and raid5.
865 • between raid4/raid5 and raid6.
867 • between striped/raid0 and raid10.
869 • between striped and raid4.
871 Indirect conversions
874 Converting from one raid level to another may require multiple steps,
875 converting first to intermediate raid levels.
876 linear to raid6
878 To convert an LV from linear to raid6:
880 1. convert to raid1 with two images
881 2. convert to raid5 (internally raid5_ls) with two images
882 3. convert to raid5 with three or more stripes (reshape)
883 4. convert to raid6 (internally raid6_ls_6)
884 5. convert to raid6 (internally raid6_zr, reshape)
885 The commands to perform the steps above are:
887 1. lvconvert --type raid1 --mirrors 1 LV
888 2. lvconvert --type raid5 LV
889 3. lvconvert --stripes 3 LV
890 4. lvconvert --type raid6 LV
891 5. lvconvert --type raid6 LV
892 The final conversion from raid6_ls_6 to raid6_zr is done to avoid the
894 potential write/recovery performance reduction in raid6_ls_6 because of
895 the dedicated parity device. raid6_zr rotates data and parity blocks
896 to avoid this.
897 linear to striped
899 To convert an LV from linear to striped:
901 1. convert to raid1 with two images
902 2. convert to raid5_n
903 3. convert to raid5_n with five 128k stripes (reshape)
904 4. convert raid5_n to striped
905 The commands to perform the steps above are:
907 1. lvconvert --type raid1 --mirrors 1 LV
908 2. lvconvert --type raid5_n LV
909 3. lvconvert --stripes 5 --stripesize 128k LV
910 4. lvconvert --type striped LV
911 The raid5_n type in step 2 is used because it has dedicated parity Sub‐
913 LVs at the end, and can be converted to striped directly. The stripe
914 size is increased in step 3 to add extra space for the conversion
915 process. This step grows the LV size by a factor of five. After con‐
916 version, this extra space can be reduced (or used to grow the file sys‐
917 tem using the LV).
918 Reversing these steps will convert a striped LV to linear.
920 raid6 to striped
922 To convert an LV from raid6_nr to striped:
924 1. convert to raid6_n_6
925 2. convert to striped
926 The commands to perform the steps above are:
928 1. lvconvert --type raid6_n_6 LV
929 2. lvconvert --type striped LV
930 Examples
934 Converting an LV from linear to raid1.
935 # lvs -a -o name,segtype,size vg
937 LV Type LSize
938 lv linear 300.00g
939 # lvconvert --type raid1 --mirrors 1 vg/lv
941 # lvs -a -o name,segtype,size vg
943 LV Type LSize
944 lv raid1 300.00g
945 [lv_rimage_0] linear 300.00g
946 [lv_rimage_1] linear 300.00g
947 [lv_rmeta_0] linear 3.00m
948 [lv_rmeta_1] linear 3.00m
949 Converting an LV from mirror to raid1.
951 # lvs -a -o name,segtype,size vg
953 LV Type LSize
954 lv mirror 100.00g
955 [lv_mimage_0] linear 100.00g
956 [lv_mimage_1] linear 100.00g
957 [lv_mlog] linear 3.00m
958 # lvconvert --type raid1 vg/lv
960 # lvs -a -o name,segtype,size vg
962 LV Type LSize
963 lv raid1 100.00g
964 [lv_rimage_0] linear 100.00g
965 [lv_rimage_1] linear 100.00g
966 [lv_rmeta_0] linear 3.00m
967 [lv_rmeta_1] linear 3.00m
968 Converting an LV from linear to raid1 (with 3 images).
970 # lvconvert --type raid1 --mirrors 2 vg/lv
972 Converting an LV from striped (with 4 stripes) to raid6_n_6.
974 # lvcreate --stripes 4 -L64M -n lv vg
976 # lvconvert --type raid6 vg/lv
978 # lvs -a -o lv_name,segtype,sync_percent,data_copies
980 LV Type Cpy%Sync #Cpy
981 lv raid6_n_6 100.00 3
982 [lv_rimage_0] linear
983 [lv_rimage_1] linear
984 [lv_rimage_2] linear
985 [lv_rimage_3] linear
986 [lv_rimage_4] linear
987 [lv_rimage_5] linear
988 [lv_rmeta_0] linear
989 [lv_rmeta_1] linear
990 [lv_rmeta_2] linear
991 [lv_rmeta_3] linear
992 [lv_rmeta_4] linear
993 [lv_rmeta_5] linear
994 This convert begins by allocating MetaLVs (rmeta_#) for each of the ex‐
996 isting stripe devices. It then creates 2 additional MetaLV/DataLV
997 pairs (rmeta_#/rimage_#) for dedicated raid6 parity.
998 If rotating data/parity is required, such as with raid6_nr, it must be
1000 done by reshaping (see below).
1001
1005 RAID reshaping is changing attributes of a RAID LV while keeping the
1006 same RAID level. This includes changing RAID layout, stripe size, or
1007 number of stripes.
1008 When changing the RAID layout or stripe size, no new SubLVs (MetaLVs or
1010 DataLVs) need to be allocated, but DataLVs are extended by a small
1011 amount (typically 1 extent). The extra space allows blocks in a stripe
1012 to be updated safely, and not be corrupted in case of a crash. If a
1013 crash occurs, reshaping can just be restarted.
1014 (If blocks in a stripe were updated in place, a crash could leave them
1016 partially updated and corrupted. Instead, an existing stripe is qui‐
1017 esced, read, changed in layout, and the new stripe written to free
1018 space. Once that is done, the new stripe is unquiesced and used.)
1019 Examples
1022 (Command output shown in examples may change.)
1023 Converting raid6_n_6 to raid6_nr with rotating data/parity.
1025 This conversion naturally follows a previous conversion from
1027 striped/raid0 to raid6_n_6 (shown above). It completes the transition
1028 to a more traditional RAID6.
1029 # lvs -o lv_name,segtype,sync_percent,data_copies
1031 LV Type Cpy%Sync #Cpy
1032 lv raid6_n_6 100.00 3
1033 [lv_rimage_0] linear
1034 [lv_rimage_1] linear
1035 [lv_rimage_2] linear
1036 [lv_rimage_3] linear
1037 [lv_rimage_4] linear
1038 [lv_rimage_5] linear
1039 [lv_rmeta_0] linear
1040 [lv_rmeta_1] linear
1041 [lv_rmeta_2] linear
1042 [lv_rmeta_3] linear
1043 [lv_rmeta_4] linear
1044 [lv_rmeta_5] linear
1045 # lvconvert --type raid6_nr vg/lv
1047 # lvs -a -o lv_name,segtype,sync_percent,data_copies
1049 LV Type Cpy%Sync #Cpy
1050 lv raid6_nr 100.00 3
1051 [lv_rimage_0] linear
1052 [lv_rimage_0] linear
1053 [lv_rimage_1] linear
1054 [lv_rimage_1] linear
1055 [lv_rimage_2] linear
1056 [lv_rimage_2] linear
1057 [lv_rimage_3] linear
1058 [lv_rimage_3] linear
1059 [lv_rimage_4] linear
1060 [lv_rimage_5] linear
1061 [lv_rmeta_0] linear
1062 [lv_rmeta_1] linear
1063 [lv_rmeta_2] linear
1064 [lv_rmeta_3] linear
1065 [lv_rmeta_4] linear
1066 [lv_rmeta_5] linear
1067 The DataLVs are larger (additional segment in each) which provides
1069 space for out-of-place reshaping. The result is:
1070 # lvs -a -o lv_name,segtype,seg_pe_ranges,dataoffset
1072 LV Type PE Ranges DOff
1073 lv raid6_nr lv_rimage_0:0-32 \
1074 lv_rimage_1:0-32 \
1075 lv_rimage_2:0-32 \
1076 lv_rimage_3:0-32
1077 [lv_rimage_0] linear /dev/sda:0-31 2048
1078 [lv_rimage_0] linear /dev/sda:33-33
1079 [lv_rimage_1] linear /dev/sdaa:0-31 2048
1080 [lv_rimage_1] linear /dev/sdaa:33-33
1081 [lv_rimage_2] linear /dev/sdab:1-33 2048
1082 [lv_rimage_3] linear /dev/sdac:1-33 2048
1083 [lv_rmeta_0] linear /dev/sda:32-32
1084 [lv_rmeta_1] linear /dev/sdaa:32-32
1085 [lv_rmeta_2] linear /dev/sdab:0-0
1086 [lv_rmeta_3] linear /dev/sdac:0-0
1087 All segments with PE ranges '33-33' provide the out-of-place reshape
1089 space. The dataoffset column shows that the data was moved from ini‐
1090 tial offset 0 to 2048 sectors on each component DataLV.
1091 For performance reasons the raid6_nr RaidLV can be restriped. Convert
1093 it from 3-way striped to 5-way-striped.
1094 # lvconvert --stripes 5 vg/lv
1096 Using default stripesize 64.00 KiB.
1097 WARNING: Adding stripes to active logical volume vg/lv will \
1098 grow it from 99 to 165 extents!
1099 Run "lvresize -l99 vg/lv" to shrink it or use the additional \
1100 capacity.
1101 Logical volume vg/lv successfully converted.
1102 # lvs vg/lv
1104 LV VG Attr LSize Cpy%Sync
1105 lv vg rwi-a-r-s- 652.00m 52.94
1106 # lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1108 LV Attr Type PE Ranges DOff
1109 lv rwi-a-r--- raid6_nr lv_rimage_0:0-33 \
1110 lv_rimage_1:0-33 \
1111 lv_rimage_2:0-33 ... \
1112 lv_rimage_5:0-33 \
1113 lv_rimage_6:0-33 0
1114 [lv_rimage_0] iwi-aor--- linear /dev/sda:0-32 0
1115 [lv_rimage_0] iwi-aor--- linear /dev/sda:34-34
1116 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:0-32 0
1117 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-34
1118 [lv_rimage_2] iwi-aor--- linear /dev/sdab:0-32 0
1119 [lv_rimage_2] iwi-aor--- linear /dev/sdab:34-34
1120 [lv_rimage_3] iwi-aor--- linear /dev/sdac:1-34 0
1121 [lv_rimage_4] iwi-aor--- linear /dev/sdad:1-34 0
1122 [lv_rimage_5] iwi-aor--- linear /dev/sdae:1-34 0
1123 [lv_rimage_6] iwi-aor--- linear /dev/sdaf:1-34 0
1124 [lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
1125 [lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
1126 [lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
1127 [lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
1128 [lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
1129 [lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
1130 [lv_rmeta_6] ewi-aor--- linear /dev/sdaf:0-0
1131 Stripes also can be removed from raid5 and 6. Convert the 5-way
1133 striped raid6_nr LV to 4-way-striped. The force option needs to be
1134 used, because removing stripes (i.e. image SubLVs) from a RaidLV will
1135 shrink its size.
1136 # lvconvert --stripes 4 vg/lv
1138 Using default stripesize 64.00 KiB.
1139 WARNING: Removing stripes from active logical volume vg/lv will \
1140 shrink it from 660.00 MiB to 528.00 MiB!
1141 THIS MAY DESTROY (PARTS OF) YOUR DATA!
1142 If that leaves the logical volume larger than 206 extents due \
1143 to stripe rounding,
1144 you may want to grow the content afterwards (filesystem etc.)
1145 WARNING: to remove freed stripes after the conversion has finished,\
1146 you have to run "lvconvert --stripes 4 vg/lv"
1147 Logical volume vg/lv successfully converted.
1148 # lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1150 LV Attr Type PE Ranges DOff
1151 lv rwi-a-r-s- raid6_nr lv_rimage_0:0-33 \
1152 lv_rimage_1:0-33 \
1153 lv_rimage_2:0-33 ... \
1154 lv_rimage_5:0-33 \
1155 lv_rimage_6:0-33 0
1156 [lv_rimage_0] Iwi-aor--- linear /dev/sda:0-32 0
1157 [lv_rimage_0] Iwi-aor--- linear /dev/sda:34-34
1158 [lv_rimage_1] Iwi-aor--- linear /dev/sdaa:0-32 0
1159 [lv_rimage_1] Iwi-aor--- linear /dev/sdaa:34-34
1160 [lv_rimage_2] Iwi-aor--- linear /dev/sdab:0-32 0
1161 [lv_rimage_2] Iwi-aor--- linear /dev/sdab:34-34
1162 [lv_rimage_3] Iwi-aor--- linear /dev/sdac:1-34 0
1163 [lv_rimage_4] Iwi-aor--- linear /dev/sdad:1-34 0
1164 [lv_rimage_5] Iwi-aor--- linear /dev/sdae:1-34 0
1165 [lv_rimage_6] Iwi-aor-R- linear /dev/sdaf:1-34 0
1166 [lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
1167 [lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
1168 [lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
1169 [lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
1170 [lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
1171 [lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
1172 [lv_rmeta_6] ewi-aor-R- linear /dev/sdaf:0-0
1173 The 's' in column 9 of the attribute field shows the RaidLV is still
1175 reshaping. The 'R' in the same column of the attribute field shows the
1176 freed image Sub LVs which will need removing once the reshaping fin‐
1177 ished.
1178 # lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1180 LV Attr Type PE Ranges DOff
1181 lv rwi-a-r-R- raid6_nr lv_rimage_0:0-33 \
1182 lv_rimage_1:0-33 \
1183 lv_rimage_2:0-33 ... \
1184 lv_rimage_5:0-33 \
1185 lv_rimage_6:0-33 8192
1186 Now that the reshape is finished the 'R' atribute on the RaidLV shows
1188 images can be removed.
1189 # lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1191 LV Attr Type PE Ranges DOff
1192 lv rwi-a-r-R- raid6_nr lv_rimage_0:0-33 \
1193 lv_rimage_1:0-33 \
1194 lv_rimage_2:0-33 ... \
1195 lv_rimage_5:0-33 \
1196 lv_rimage_6:0-33 8192
1197 This is achieved by repeating the command ("lvconvert --stripes 4
1199 vg/lv" would be sufficient).
1200 # lvconvert --stripes 4 vg/lv
1202 Using default stripesize 64.00 KiB.
1203 Logical volume vg/lv successfully converted.
1204 # lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1206 LV Attr Type PE Ranges DOff
1207 lv rwi-a-r--- raid6_nr lv_rimage_0:0-33 \
1208 lv_rimage_1:0-33 \
1209 lv_rimage_2:0-33 ... \
1210 lv_rimage_5:0-33 8192
1211 [lv_rimage_0] iwi-aor--- linear /dev/sda:0-32 8192
1212 [lv_rimage_0] iwi-aor--- linear /dev/sda:34-34
1213 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:0-32 8192
1214 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-34
1215 [lv_rimage_2] iwi-aor--- linear /dev/sdab:0-32 8192
1216 [lv_rimage_2] iwi-aor--- linear /dev/sdab:34-34
1217 [lv_rimage_3] iwi-aor--- linear /dev/sdac:1-34 8192
1218 [lv_rimage_4] iwi-aor--- linear /dev/sdad:1-34 8192
1219 [lv_rimage_5] iwi-aor--- linear /dev/sdae:1-34 8192
1220 [lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
1221 [lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
1222 [lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
1223 [lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
1224 [lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
1225 [lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
1226 # lvs -a -o lv_name,attr,segtype,reshapelen vg
1228 LV Attr Type RSize
1229 lv rwi-a-r--- raid6_nr 24.00m
1230 [lv_rimage_0] iwi-aor--- linear 4.00m
1231 [lv_rimage_0] iwi-aor--- linear
1232 [lv_rimage_1] iwi-aor--- linear 4.00m
1233 [lv_rimage_1] iwi-aor--- linear
1234 [lv_rimage_2] iwi-aor--- linear 4.00m
1235 [lv_rimage_2] iwi-aor--- linear
1236 [lv_rimage_3] iwi-aor--- linear 4.00m
1237 [lv_rimage_4] iwi-aor--- linear 4.00m
1238 [lv_rimage_5] iwi-aor--- linear 4.00m
1239 [lv_rmeta_0] ewi-aor--- linear
1240 [lv_rmeta_1] ewi-aor--- linear
1241 [lv_rmeta_2] ewi-aor--- linear
1242 [lv_rmeta_3] ewi-aor--- linear
1243 [lv_rmeta_4] ewi-aor--- linear
1244 [lv_rmeta_5] ewi-aor--- linear
1245 Future developments might include automatic removal of the freed im‐
1247 ages.
1248 If the reshape space shall be removed any lvconvert command not chang‐
1250 ing the layout can be used:
1251 # lvconvert --stripes 4 vg/lv
1253 Using default stripesize 64.00 KiB.
1254 No change in RAID LV vg/lv layout, freeing reshape space.
1255 Logical volume vg/lv successfully converted.
1256 # lvs -a -o lv_name,attr,segtype,reshapelen vg
1258 LV Attr Type RSize
1259 lv rwi-a-r--- raid6_nr 0
1260 [lv_rimage_0] iwi-aor--- linear 0
1261 [lv_rimage_0] iwi-aor--- linear
1262 [lv_rimage_1] iwi-aor--- linear 0
1263 [lv_rimage_1] iwi-aor--- linear
1264 [lv_rimage_2] iwi-aor--- linear 0
1265 [lv_rimage_2] iwi-aor--- linear
1266 [lv_rimage_3] iwi-aor--- linear 0
1267 [lv_rimage_4] iwi-aor--- linear 0
1268 [lv_rimage_5] iwi-aor--- linear 0
1269 [lv_rmeta_0] ewi-aor--- linear
1270 [lv_rmeta_1] ewi-aor--- linear
1271 [lv_rmeta_2] ewi-aor--- linear
1272 [lv_rmeta_3] ewi-aor--- linear
1273 [lv_rmeta_4] ewi-aor--- linear
1274 [lv_rmeta_5] ewi-aor--- linear
1275 In case the RaidLV should be converted to striped:
1277 # lvconvert --type striped vg/lv
1279 Unable to convert LV vg/lv from raid6_nr to striped.
1280 Converting vg/lv from raid6_nr is directly possible to the \
1281 following layouts:
1282 raid6_nc
1283 raid6_zr
1284 raid6_la_6
1285 raid6_ls_6
1286 raid6_ra_6
1287 raid6_rs_6
1288 raid6_n_6
1289 A direct conversion isn't possible thus the command informed about the
1291 possible ones. raid6_n_6 is suitable to convert to striped so convert
1292 to it first (this is a reshape changing the raid6 layout from raid6_nr
1293 to raid6_n_6).
1294 # lvconvert --type raid6_n_6
1296 Using default stripesize 64.00 KiB.
1297 Converting raid6_nr LV vg/lv to raid6_n_6.
1298 Are you sure you want to convert raid6_nr LV vg/lv? [y/n]: y
1299 Logical volume vg/lv successfully converted.
1300 Wait for the reshape to finish.
1302 # lvconvert --type striped vg/lv
1304 Logical volume vg/lv successfully converted.
1305 # lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1307 LV Attr Type PE Ranges DOff
1308 lv -wi-a----- striped /dev/sda:2-32 \
1309 /dev/sdaa:2-32 \
1310 /dev/sdab:2-32 \
1311 /dev/sdac:3-33
1312 lv -wi-a----- striped /dev/sda:34-35 \
1313 /dev/sdaa:34-35 \
1314 /dev/sdab:34-35 \
1315 /dev/sdac:34-35
1316 From striped we can convert to raid10
1318 # lvconvert --type raid10 vg/lv
1320 Using default stripesize 64.00 KiB.
1321 Logical volume vg/lv successfully converted.
1322 # lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1324 LV Attr Type PE Ranges DOff
1325 lv rwi-a-r--- raid10 lv_rimage_0:0-32 \
1326 lv_rimage_4:0-32 \
1327 lv_rimage_1:0-32 ... \
1328 lv_rimage_3:0-32 \
1329 lv_rimage_7:0-32 0
1330 # lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
1332 WARNING: Cannot find matching striped segment for vg/lv_rimage_3.
1333 LV Attr Type PE Ranges DOff
1334 lv rwi-a-r--- raid10 lv_rimage_0:0-32 \
1335 lv_rimage_4:0-32 \
1336 lv_rimage_1:0-32 ... \
1337 lv_rimage_3:0-32 \
1338 lv_rimage_7:0-32 0
1339 [lv_rimage_0] iwi-aor--- linear /dev/sda:2-32 0
1340 [lv_rimage_0] iwi-aor--- linear /dev/sda:34-35
1341 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:2-32 0
1342 [lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-35
1343 [lv_rimage_2] iwi-aor--- linear /dev/sdab:2-32 0
1344 [lv_rimage_2] iwi-aor--- linear /dev/sdab:34-35
1345 [lv_rimage_3] iwi-XXr--- linear /dev/sdac:3-35 0
1346 [lv_rimage_4] iwi-aor--- linear /dev/sdad:1-33 0
1347 [lv_rimage_5] iwi-aor--- linear /dev/sdae:1-33 0
1348 [lv_rimage_6] iwi-aor--- linear /dev/sdaf:1-33 0
1349 [lv_rimage_7] iwi-aor--- linear /dev/sdag:1-33 0
1350 [lv_rmeta_0] ewi-aor--- linear /dev/sda:0-0
1351 [lv_rmeta_1] ewi-aor--- linear /dev/sdaa:0-0
1352 [lv_rmeta_2] ewi-aor--- linear /dev/sdab:0-0
1353 [lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
1354 [lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
1355 [lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
1356 [lv_rmeta_6] ewi-aor--- linear /dev/sdaf:0-0
1357 [lv_rmeta_7] ewi-aor--- linear /dev/sdag:0-0
1358 raid10 allows to add stripes but can't remove them.
1360 A more elaborate example to convert from linear to striped with interim
1363 conversions to raid1 then raid5 followed by restripe (4 steps).
1364 We start with the linear LV.
1366 # lvs -a -o name,size,segtype,syncpercent,datastripes,\
1368 stripesize,reshapelenle,devices vg
1369 LV LSize Type Cpy%Sync #DStr Stripe RSize Devices
1370 lv 128.00m linear 1 0 /dev/sda(0)
1371 Then convert it to a 2-way raid1.
1373 # lvconvert --mirrors 1 vg/lv
1375 Logical volume vg/lv successfully converted.
1376 # lvs -a -o name,size,segtype,datastripes,\
1378 stripesize,reshapelenle,devices vg
1379 LV LSize Type #DStr Stripe RSize Devices
1380 lv 128.00m raid1 2 0 lv_rimage_0(0),\
1381 lv_rimage_1(0)
1382 [lv_rimage_0] 128.00m linear 1 0 /dev/sda(0)
1383 [lv_rimage_1] 128.00m linear 1 0 /dev/sdhx(1)
1384 [lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
1385 [lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)
1386 Once the raid1 LV is fully synchronized we convert it to raid5_n (only
1388 2-way raid1 LVs can be converted to raid5). We select raid5_n here be‐
1389 cause it has dedicated parity SubLVs at the end and can be converted to
1390 striped directly without any additional conversion.
1391 # lvconvert --type raid5_n vg/lv
1393 Using default stripesize 64.00 KiB.
1394 Logical volume vg/lv successfully converted.
1395 # lvs -a -o name,size,segtype,syncpercent,datastripes,\
1397 stripesize,reshapelenle,devices vg
1398 LV LSize Type #DStr Stripe RSize Devices
1399 lv 128.00m raid5_n 1 64.00k 0 lv_rimage_0(0),\
1400 lv_rimage_1(0)
1401 [lv_rimage_0] 128.00m linear 1 0 0 /dev/sda(0)
1402 [lv_rimage_1] 128.00m linear 1 0 0 /dev/sdhx(1)
1403 [lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
1404 [lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)
1405 Now we'll change the number of data stripes from 1 to 5 and request
1407 128K stripe size in one command. This will grow the size of the LV by
1408 a factor of 5 (we add 4 data stripes to the one given). That additonal
1409 space can be used by e.g. growing any contained filesystem or the LV
1410 can be reduced in size after the reshaping conversion has finished.
1411 # lvconvert --stripesize 128k --stripes 5 vg/lv
1413 Converting stripesize 64.00 KiB of raid5_n LV vg/lv to 128.00 KiB.
1414 WARNING: Adding stripes to active logical volume vg/lv will grow \
1415 it from 32 to 160 extents!
1416 Run "lvresize -l32 vg/lv" to shrink it or use the additional capacity.
1417 Logical volume vg/lv successfully converted.
1418 # lvs -a -o name,size,segtype,datastripes,\
1420 stripesize,reshapelenle,devices
1421 LV LSize Type #DStr Stripe RSize Devices
1422 lv 640.00m raid5_n 5 128.00k 6 lv_rimage_0(0),\
1423 lv_rimage_1(0),\
1424 lv_rimage_2(0),\
1425 lv_rimage_3(0),\
1426 lv_rimage_4(0),\
1427 lv_rimage_5(0)
1428 [lv_rimage_0] 132.00m linear 1 0 1 /dev/sda(33)
1429 [lv_rimage_0] 132.00m linear 1 0 /dev/sda(0)
1430 [lv_rimage_1] 132.00m linear 1 0 1 /dev/sdhx(33)
1431 [lv_rimage_1] 132.00m linear 1 0 /dev/sdhx(1)
1432 [lv_rimage_2] 132.00m linear 1 0 1 /dev/sdhw(33)
1433 [lv_rimage_2] 132.00m linear 1 0 /dev/sdhw(1)
1434 [lv_rimage_3] 132.00m linear 1 0 1 /dev/sdhv(33)
1435 [lv_rimage_3] 132.00m linear 1 0 /dev/sdhv(1)
1436 [lv_rimage_4] 132.00m linear 1 0 1 /dev/sdhu(33)
1437 [lv_rimage_4] 132.00m linear 1 0 /dev/sdhu(1)
1438 [lv_rimage_5] 132.00m linear 1 0 1 /dev/sdht(33)
1439 [lv_rimage_5] 132.00m linear 1 0 /dev/sdht(1)
1440 [lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
1441 [lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)
1442 [lv_rmeta_2] 4.00m linear 1 0 /dev/sdhw(0)
1443 [lv_rmeta_3] 4.00m linear 1 0 /dev/sdhv(0)
1444 [lv_rmeta_4] 4.00m linear 1 0 /dev/sdhu(0)
1445 [lv_rmeta_5] 4.00m linear 1 0 /dev/sdht(0)
1446 Once the conversion has finished we can can convert to striped.
1448 # lvconvert --type striped vg/lv
1450 Logical volume vg/lv successfully converted.
1451 # lvs -a -o name,size,segtype,datastripes,\
1453 stripesize,reshapelenle,devices vg
1454 LV LSize Type #DStr Stripe RSize Devices
1455 lv 640.00m striped 5 128.00k /dev/sda(33),\
1456 /dev/sdhx(33),\
1457 /dev/sdhw(33),\
1458 /dev/sdhv(33),\
1459 /dev/sdhu(33)
1460 lv 640.00m striped 5 128.00k /dev/sda(0),\
1461 /dev/sdhx(1),\
1462 /dev/sdhw(1),\
1463 /dev/sdhv(1),\
1464 /dev/sdhu(1)
1465 Reversing these steps will convert a given striped LV to linear.
1467 Mind the facts that stripes are removed thus the capacity of the RaidLV
1469 will shrink and that changing the RaidLV layout will influence its per‐
1470 formance.
1471 "lvconvert --stripes 1 vg/lv" for converting to 1 stripe will inform
1473 upfront about the reduced size to allow for resizing the content or
1474 growing the RaidLV before actually converting to 1 stripe. The --force
1475 option is needed to allow stripe removing conversions to prevent data
1476 loss.
1477 Of course any interim step can be the intended last one (e.g. striped->
1479 raid1).
1480
1483 raid5_ls
1484 • RAID5 left symmetric
1485 • Rotating parity N with data restart
1486 raid5_la
1488 • RAID5 left symmetric
1489 • Rotating parity N with data continuation
1490 raid5_rs
1492 • RAID5 right symmetric
1493 • Rotating parity 0 with data restart
1494 raid5_ra
1496 • RAID5 right asymmetric
1497 • Rotating parity 0 with data continuation
1498 raid5_n
1500 • RAID5 parity n
1501 • Dedicated parity device n used for striped/raid0 conversions
1502 • Used for RAID Takeover
1503
1506 raid6
1507 • RAID6 zero restart (aka left symmetric)
1508 • Rotating parity 0 with data restart
1509 • Same as raid6_zr
1510 raid6_zr
1512 • RAID6 zero restart (aka left symmetric)
1513 • Rotating parity 0 with data restart
1514 raid6_nr
1516 • RAID6 N restart (aka right symmetric)
1517 • Rotating parity N with data restart
1518 raid6_nc
1520 • RAID6 N continue
1521 • Rotating parity N with data continuation
1522 raid6_n_6
1524 • RAID6 last parity devices
1525 • Fixed dedicated last devices (P-Syndrome N-1 and Q-Syndrome N)
1526 with striped data used for striped/raid0 conversions
1527 • Used for RAID Takeover
1528 raid6_{ls,rs,la,ra}_6
1530 • RAID6 last parity device
1531 • Dedicated last parity device used for conversions from/to
1532 raid5_{ls,rs,la,ra}
1533 raid6_ls_6
1535 • RAID6 N continue
1536 • Same as raid5_ls for N-1 devices with fixed Q-Syndrome N
1537 • Used for RAID Takeover
1538 raid6_la_6
1540 • RAID6 N continue
1541 • Same as raid5_la for N-1 devices with fixed Q-Syndrome N
1542 • Used forRAID Takeover
1543 raid6_rs_6
1545 • RAID6 N continue
1546 • Same as raid5_rs for N-1 devices with fixed Q-Syndrome N
1547 • Used for RAID Takeover
1548 raid6_ra_6
1550 • RAID6 N continue
1551 • ame as raid5_ra for N-1 devices with fixed Q-Syndrome N
1552 • Used for RAID Takeover
1553
1558 The 2.6.38-rc1 version of the Linux kernel introduced a device-mapper
1559 target to interface with the software RAID (MD) personalities. This
1560 provided device-mapper with RAID 4/5/6 capabilities and a larger devel‐
1561 opment community. Later, support for RAID1, RAID10, and RAID1E (RAID
1562 10 variants) were added. Support for these new kernel RAID targets was
1563 added to LVM version 2.02.87. The capabilities of the LVM raid1 type
1564 have surpassed the old mirror type. raid1 is now recommended instead
1565 of mirror. raid1 became the default for mirroring in LVM version
1566 2.02.100.
1567Red Hat, Inc LVM TOOLS 2.03.11(2) (2021-01-08) LVMRAID(7)