LVMRAID(7)
✨ NAME ✨
lvmraid — LVM RAID. (this whole page is LVMRAID(7), bestie, and it's giving "let's raid some logical volumes" 💅)
🌈 DESCRIPTION 🌈
okay so first things first: lvm(8) RAID is literally a way to create a Logical Volume (LV) that uses multiple physical devices to either glow up your performance or survive when a device decides to ghost you. In LVM world, those physical devices are called Physical Volumes (PVs), and they all live together in one Volume Group (VG) — it's giving polycule but for storage 💅.
How your LV data blocks get placed onto those PVs? That's decided by the RAID level. You'll see them named like raid plus a number — raid1, raid5, raid6, etc. Picking a RAID level is a whole tradeoff situation among: physical device requirements, fault tolerance, and performance. If you want the full academic tea on RAID levels, it's at: Technical_Position.pdf 📄.
LVM RAID uses both the Device Mapper (DM) and Multiple Device (MD) drivers from the Linux kernel. DM handles creating and managing the visible LVM devices, and MD is the one placing data on the actual physical devices. teamwork makes the dream work ✨.
LVM creates hidden LVs (dm devices) that layer between the visible LV and the physical devices. The LVs in those middle layers? They're called sub LVs. For LVM raid, a sub LV pair gets created for every raid image/leg — one for data and one for metadata (that's the raid superblock and the write intent bitmap). If you wanna see this in action, check the lvs(8) command examples below 👀.
💖 USAGE 💖
To create a RAID LV, you use lvcreate and tell it an LV type. That LV type corresponds to a RAID level. The basic RAID levels you can use are: raid0, raid1, raid4, raid5, raid6, raid10. yes bestie, pick your fighter.
The general vibe is:
lvcreate --type RaidLevel [OPTIONS] --name Name --size Size VG [PVs]Wanna see what LV type an existing LV has? Run:
# lvs -o name,segtype LV(btw, the LV type is also called "segment type" or "segtype" — same thing, different nickname 💅)
LVs can be created with the following types:
✨ raid0 ✨
Also called striping. raid0 spreads LV data across multiple devices in units of stripe size. It's used to increase performance. But fair warning: LV data will be lost if any of the devices fail. no cap, it's fast but fragile 😭.
lvcreate --type raid0 [--stripes Number --stripesize Size] VG [PVs]--stripes Number— specifies theNumberof devices to spread the LV across.--stripesize Size— specifies theSizeof each stripe in kilobytes. This is the amount of data that is written to one device before moving to the next.PVs— specifies the devices to use. If you don't specify, lvm will chooseNumberdevices, one for each stripe, based on the number of PVs available or supplied.
🦋 raid1 🦋
Also called mirroring. raid1 uses multiple devices to duplicate LV data. The LV data remains available if all but one of the devices fail. The minimum number of devices (i.e. sub LV pairs) required is 2. it's giving "have a backup bestie" energy 🫶.
lvcreate --type raid1 [--mirrors Number] VG [PVs]--mirrors Number— specifies theNumberof mirror images in addition to the original LV image. e.g.--mirrors 1means there are two images of the data, the original and one mirror image.PVs— specifies the devices to use. If not specified, lvm will chooseNumberdevices, one for each image.
🌸 raid4 🌸
raid4 is a form of striping that uses an extra, first device dedicated to storing parity blocks. The LV data remains available if one device fails. The parity is used to recalculate data that is lost from a single device. The minimum number of devices required is 3.
lvcreate --type raid4 [--stripes Number --stripesize Size] VG [PVs]--stripes Number— specifies theNumberof devices to use for LV data. This does not include the extra device lvm adds for storing parity blocks. A raid4 LV withNumberstripes requiresNumber+1devices.Numbermust be 2 or more.--stripesize Size— specifies theSizeof each stripe in kilobytes. This is the amount of data that is written to one device before moving to the next.PVs— specifies the devices to use. If not specified, lvm will chooseNumber+1separate devices.
raid4 is called non-rotating parity because the parity blocks are always stored on the same device. it's loyal like that 💀.
🎀 raid5 🎀
raid5 is a form of striping that uses an extra device for storing parity blocks. LV data and parity blocks are stored on each device, typically in a rotating pattern for performance reasons. The LV data remains available if one device fails. The parity is used to recalculate data that is lost from a single device. The minimum number of devices required is 3 (unless you're converting from 2 legged raid1 to reshape to more stripes; see reshaping).
lvcreate --type raid5 [--stripes Number --stripesize Size] VG [PVs]--stripes Number— specifies theNumberof devices to use for LV data. This does not include the extra device lvm adds for storing parity blocks. A raid5 LV withNumberstripes requiresNumber+1devices.Numbermust be 2 or more.--stripesize Size— specifies theSizeof each stripe in kilobytes. This is the amount of data that is written to one device before moving to the next.PVs— specifies the devices to use. If not specified, lvm will chooseNumber+1separate devices.
raid5 is called rotating parity because the parity blocks are placed on different devices in a round-robin sequence. There are variations of raid5 with different algorithms for placing the parity blocks. The default variant is raid5_ls (raid5 left symmetric, which is a rotating parity 0 with data restart). See RAID5 VARIANTS below. 👑
🌟 raid6 🌟
raid6 is a form of striping like raid5, but uses two extra devices for parity blocks. LV data and parity blocks are stored on each device, typically in a rotating pattern for performance reasons. The LV data remains available if up to two devices fail. The parity is used to recalculate data that is lost from one or two devices. The minimum number of devices required is 5.
lvcreate --type raid6 [--stripes Number --stripesize Size] VG [PVs]--stripes Number— specifies theNumberof devices to use for LV data. This does not include the extra two devices lvm adds for storing parity blocks. A raid6 LV withNumberstripes requiresNumber+2devices.Numbermust be 3 or more.--stripesize Size— specifies theSizeof each stripe in kilobytes. This is the amount of data that is written to one device before moving to the next.PVs— specifies the devices to use. If not specified, lvm will chooseNumber+2separate devices.
Like raid5, there are variations of raid6 with different algorithms for placing the parity blocks. The default variant is raid6_zr (raid6 zero restart, aka left symmetric, which is a rotating parity 0 with data restart). See RAID6 VARIANTS below. 💜
🌈 raid10 🌈
raid10 is a combination of raid1 and raid0 — striping data across mirrored devices. LV data remains available if one or more devices remains in each mirror set. The minimum number of devices required is 4.
lvcreate --type raid10 [--mirrors NumberMirrors]
[--stripes NumberStripes --stripesize Size] VG [PVs]--mirrors NumberMirrors— specifies the number of mirror images within each stripe. e.g.--mirrors 1means there are two images of the data, the original and one mirror image.--stripes NumberStripes— specifies the total number of devices to use in all raid1 images (not the number of raid1 devices to spread the LV across, even though that is the effective result). The number of devices in each raid1 mirror will beNumberStripes/(NumberMirrors+1), e.g. mirrors 1 and stripes 4 will stripe data across two raid1 mirrors, where each mirror contains two devices.--stripesize Size— specifies theSizeof each stripe in kilobytes. This is the amount of data that is written to one device before moving to the next.PVs— specifies the devices to use. If not specified, lvm will choose the necessary devices. Devices are used to create mirrors in the order listed, e.g. for mirrors 1, stripes 2, listingPV1 PV2 PV3 PV4results in mirrorsPV1/PV2andPV3/PV4.
RAID10 is NOT mirroring on top of stripes (which would be RAID01 and is less tolerant of device failures). so don't get it twisted, bestie 🙈.
⚙️ Configuration Options ⚙️
There are a number of options in the lvm.conf(5) configuration file that affect the behavior of RAID LVs. The tunable options are listed below. A detailed description of each can be found in the lvm.conf(5) configuration file itself.
global/mirror_segtype_defaultglobal/raid10_segtype_defaultactivation/raid_region_sizeactivation/raid_fault_policyactivation/activation_mode
👀 Monitoring 👀
When a RAID LV is activated, the dmeventd(8) process is started to monitor the health of the LV. Various events detected in the kernel can cause a notification to be sent from device-mapper to the monitoring process, including device failures and synchronization completion (e.g. for initialization or scrubbing).
The LVM configuration file contains options that affect how the monitoring process will respond to failure events (e.g. raid_fault_policy). It is possible to turn on and off monitoring with lvchange, but it is not recommended to turn this off unless you have a thorough knowledge of the consequences. seriously, don't touch unless you know what you're doing 💀.
🔄 Synchronization 🔄
Synchronization is the process that makes all the devices in a RAID LV consistent with each other. it's like a group chat where everyone needs to be on the same page, fr fr.
In a RAID1 LV, all mirror images should have the same data. When a new mirror image is added, or a mirror image is missing data, then images need to be synchronized. Data blocks are copied from an existing image to a new or outdated image to make them match.
In a RAID 4/5/6 LV, parity blocks and data blocks should match based on the parity calculation. When the devices in a RAID LV change, the data and parity blocks can become inconsistent and need to be synchronized. Correct blocks are read, parity is calculated, and recalculated blocks are written.
The RAID implementation keeps track of which parts of a RAID LV are synchronized. When a RAID LV is first created and activated, the first synchronization is called initialization. A pointer stored in the raid metadata keeps track of the initialization process thus allowing it to be restarted after a deactivation of the RaidLV or a crash. Any writes to the RaidLV dirty the respective region of the write intent bitmap which allows for fast recovery of the regions after a crash. Without this, the entire LV would need to be synchronized every time it was activated.
Automatic synchronization happens when a RAID LV is activated, but it is usually partial because the bitmaps reduce the areas that are checked. A full sync becomes necessary when devices in the RAID LV are replaced.
The sync vibe check on a RAID LV? Yeah, you can literally just ask her, and "Cpy%Sync" hitting "100%" means it's done, no cap:
# lvs -a -o name,sync_percent🧼 Scrubbing ✨
Okay so scrubbing is a full scan of the RAID LV, and you (a user) are the one requesting it. Like, you knock on the door and the whole thing gets read top to bottom. It catches problems that partial synchronization straight-up misses. 👑
Here's the tea: scrubbing assumes RAID metadata and bitmaps might be lying to you, so it verifies everything — all RAID metadata, LV data, and parity blocks. It's the paranoid bestie who double-checks the group chat receipts. So it can find inconsistencies caused by hardware errors or degradation — the kind of stuff automatic synchronization will never notice, because auto-sync skips over anything outside of the RAID write-intent bitmap. 🙈
The scrub command runs in two different modes:
lvchange --syncaction check|repair LVcheck— Check mode is read-only, bestie! It only detects inconsistent areas in the RAID LV, it does not correct them. It's giving "looking but not touching." 👀repair— Repair mode checks and writes corrected blocks to synchronize any inconsistent areas. It actually fixes the thing. 💅
Heads up: scrubbing can eat a LOT of bandwidth and slow down application I/O on the RAID LV. 🫠
So to control the I/O rate used for scrubbing, use:
--maxrecoveryrate Size[k|UNIT]— Sets the maximum recovery rate for a RAID LV.Sizeis an amount per second for each device in the array. If no suffix is given, thenKiB/sec/deviceis used. Setting the recovery rate to0means it will be unbounded. 🔥--minrecoveryrate Size[k|UNIT]— Sets the minimum recovery rate for a RAID LV.Sizeis an amount per second for each device in the array. If no suffix is given, thenKiB/sec/deviceis used. Setting the recovery rate to0means it will be unbounded. 🔥
Wanna see the current scrubbing in progress on an LV, including the syncaction mode and percent complete? Run:
# lvs -a -o name,raid_sync_action,sync_percentAnd once scrubbing is complete, to display the number of inconsistent blocks found, run:
# lvs -o name,raid_mismatch_countAlso, if mismatches were found, the lvs(8) attr field will display the letter "m" (mismatch) in the 9th position, e.g.
# lvs -o name,vgname,segtype,attr vg/lv
LV VG Type Attr
lv vg raid1 Rwi-a-r-m-🧼 Scrubbing Limitations 💀
Real talk, this part is the reality check.
The check mode can only report the number of inconsistent blocks — it cannot report which blocks are inconsistent. So it's literally impossible to know which device has errors, or whether the errors affect file system data, metadata, or nothing at all. It's giving "something's wrong but I won't say what." 😭
The repair mode can make the RAID LV data consistent, but it does not know which data is correct. So the result may be consistent but incorrect data. Yikes. When two different blocks of data must be made consistent, it chooses the block from the device that would be used during RAID initialization. However, if the PV holding corrupt data is known, lvchange --rebuild can be used in place of scrubbing to reconstruct the data on the bad device. 🛠️
Future developments might include:
- Allowing a user to choose the correct version of data during repair.
- Using a majority of devices to determine the correct version of data to use in a 3-way RAID1 or RAID6 LV.
- Using a checksumming device to pin-point when and where an error occurs, allowing it to be rewritten.
🦋 SubLVs ✨
An LV is often a combination of other hidden LVs called SubLVs. The SubLVs either use physical devices, or are built from other SubLVs themselves. SubLVs hold LV data blocks, RAID parity blocks, and RAID metadata. They're generally hidden, so you need the lvs -a option to display them:
# lvs -a -o name,segtype,devicesSubLV names begin with the visible LV name, and have an automatic suffix indicating its role:
- SubLVs holding LV data or parity blocks have the suffix
_rimage_#. These SubLVs are sometimes referred to as DataLVs. 💾 - SubLVs holding RAID metadata have the suffix
_rmeta_#. RAID metadata includes superblock information, RAID type, bitmap, and device health information. These SubLVs are sometimes referred to as MetaLVs. 🧠
Ngl bestie: SubLVs are an internal implementation detail of LVM. The way they are used, constructed and named may change. So don't get too attached. 💀
The following examples show the SubLV arrangement for each of the basic RAID LV types, using the fewest number of devices allowed for each.
Examples 🎀
raid0
Each rimage SubLV holds a portion of LV data. No parity is used. No RAID metadata is used.
# lvcreate --type raid0 --stripes 2 --name lvr0 ...
# lvs -a -o name,segtype,devices
lvr0 raid0 lvr0_rimage_0(0),lvr0_rimage_1(0)
[lvr0_rimage_0] linear /dev/sda(...)
[lvr0_rimage_1] linear /dev/sdb(...)raid1
Each rimage SubLV holds a complete copy of LV data. No parity is used. Each rmeta SubLV holds RAID metadata.
# lvcreate --type raid1 --mirrors 1 --name lvr1 ...
# lvs -a -o name,segtype,devices
lvr1 raid1 lvr1_rimage_0(0),lvr1_rimage_1(0)
[lvr1_rimage_0] linear /dev/sda(...)
[lvr1_rimage_1] linear /dev/sdb(...)
[lvr1_rmeta_0] linear /dev/sda(...)
[lvr1_rmeta_1] linear /dev/sdb(...)raid4
At least three rimage SubLVs each hold a portion of LV data and one rimage SubLV holds parity. Each rmeta SubLV holds RAID metadata.
# lvcreate --type raid4 --stripes 2 --name lvr4 ...
# lvs -a -o name,segtype,devices
lvr4 raid4 lvr4_rimage_0(0),\
lvr4_rimage_1(0),\
lvr4_rimage_2(0)
[lvr4_rimage_0] linear /dev/sda(...)
[lvr4_rimage_1] linear /dev/sdb(...)
[lvr4_rimage_2] linear /dev/sdc(...)
[lvr4_rmeta_0] linear /dev/sda(...)
[lvr4_rmeta_1] linear /dev/sdb(...)
[lvr4_rmeta_2] linear /dev/sdc(...)raid5
At least three rimage SubLVs each typically hold a portion of LV data and parity. (See section on raid5) Each rmeta SubLV holds RAID metadata.
# lvcreate --type raid5 --stripes 2 --name lvr5 ...
# lvs -a -o name,segtype,devices
lvr5 raid5 lvr5_rimage_0(0),\
lvr5_rimage_1(0),\
lvr5_rimage_2(0)
[lvr5_rimage_0] linear /dev/sda(...)
[lvr5_rimage_1] linear /dev/sdb(...)
[lvr5_rimage_2] linear /dev/sdc(...)
[lvr5_rmeta_0] linear /dev/sda(...)
[lvr5_rmeta_1] linear /dev/sdb(...)
[lvr5_rmeta_2] linear /dev/sdc(...)raid6
At least five rimage SubLVs each typically hold a portion of LV data and parity. (See section on raid6) Each rmeta SubLV holds RAID metadata.
# lvcreate --type raid6 --stripes 3 --name lvr6
# lvs -a -o name,segtype,devices
lvr6 raid6 lvr6_rimage_0(0),\
lvr6_rimage_1(0),\
lvr6_rimage_2(0),\
lvr6_rimage_3(0),\
lvr6_rimage_4(0),\
lvr6_rimage_5(0)
[lvr6_rimage_0] linear /dev/sda(...)
[lvr6_rimage_1] linear /dev/sdb(...)
[lvr6_rimage_2] linear /dev/sdc(...)
[lvr6_rimage_3] linear /dev/sdd(...)
[lvr6_rimage_4] linear /dev/sde(...)
[lvr6_rimage_5] linear /dev/sdf(...)
[lvr6_rmeta_0] linear /dev/sda(...)
[lvr6_rmeta_1] linear /dev/sdb(...)
[lvr6_rmeta_2] linear /dev/sdc(...)
[lvr6_rmeta_3] linear /dev/sdd(...)
[lvr6_rmeta_4] linear /dev/sde(...)
[lvr6_rmeta_5] linear /dev/sdf(...)raid10
At least four rimage SubLVs each hold a portion of LV data. No parity is used. Each rmeta SubLV holds RAID metadata.
# lvcreate --type raid10 --stripes 2 --mirrors 1 --name lvr10
# lvs -a -o name,segtype,devices
lvr10 raid10 lvr10_rimage_0(0),\
lvr10_rimage_1(0),\
lvr10_rimage_2(0),\
lvr10_rimage_3(0)
[lvr10_rimage_0] linear /dev/sda(...)
[lvr10_rimage_1] linear /dev/sdb(...)
[lvr10_rimage_2] linear /dev/sdc(...)
[lvr10_rimage_3] linear /dev/sdd(...)
[lvr10_rmeta_0] linear /dev/sda(...)
[lvr10_rmeta_1] linear /dev/sdb(...)
[lvr10_rmeta_2] linear /dev/sdc(...)
[lvr10_rmeta_3] linear /dev/sdd(...)💥 DEVICE FAILURE 💥
okay bestie, let's talk about the worst-case scenario, because it will happen and you need to be emotionally prepared 💀
Physical devices in a RAID LV can fail or be lost for ✨multiple✨ reasons. A device could be temporarily unavailable, or permanently gone-gone. The whole point of RAID LVs (levels 1 and up) is to keep on trucking in a degraded mode, without losing any LV data, even after a device just dies on you. But how many devices can dip out before things get tragic? Depends on the RAID level, bestie:
- RAID0 (striped) LVs cannot tolerate losing any devices. LV data will be lost if any devices fail. like, one (1) device. that's it. game over. 😭
- RAID1 LVs can tolerate losing all but one device without LV data loss. queen behavior honestly 👑
- RAID4 and RAID5 LVs can tolerate losing one device without LV data loss.
- RAID6 LVs can tolerate losing two devices without LV data loss. double the safety, double the slay.
- RAID10 is variable, and depends on which devices are lost. It stripes across multiple mirror groups with raid1 layout thus it can tolerate losing all but one device in each of these groups without LV data loss.
If a RAID LV is missing devices, or has other device-related problems, lvs(8) reports this in the health_status (and attr) fields:
# lvs -o name,lv_health_statuspartial— Devices are missing from the LV. This is also indicated by the letter"p"(partial) in the 9th position of thelvs(8)attrfield.refresh needed— A device was temporarily missing but has returned. The LV needs to be refreshed to use the device again (which will usually require partial synchronization). This is also indicated by the letter"r"(refresh needed) in the 9th position of thelvs(8)attrfield. See Refreshing an LV. This could also indicate a problem with the device, in which case it should be replaced, see Replacing Devices.mismatches exist— See Scrubbing.
Most commands will also print a warning if a device is missing, e.g.
WARNING: Device for PV uItL3Z-wBME-DQy0-... not found or rejected ...This warning will go away if the device returns or is removed from the VG. (See vgreduce(8) --removemissing).
🫶 Activating an LV with missing devices
A RAID LV that is missing devices may be activated or not, depending on the "activation mode" used in lvchange:
lvchange -ay --activationmode complete|degraded|partial LVcomplete— The LV is only activated if all devices are present. no absences allowed, attendance is mandatory 🎀degraded— The LV is activated with missing devices if the RAID level can tolerate the number of missing devices without LV data loss.partial— The LV is always activated, even if portions of the LV data are missing because of the missing device(s). This should only be used to perform extreme recovery or repair operations. > ⚠️ like, this is the emergency-emergency mode, bestie. extreme recovery only. don't just casually vibe with data loss.
Default activation mode when not specified by the command: lvm.conf(5) activation/activation_mode
The default value is printed by:
# lvmconfig --type default activation/activation_mode🔄 Replacing Devices
Devices in a RAID LV can be replaced by other devices in the VG. When replacing devices that are no longer visible on the system, use lvconvert --repair. When replacing devices that are still visible, use lvconvert --replace. The repair command will attempt to restore the same number of data LVs that were previously in the LV. The replace option can be repeated to replace multiple PVs. Replacement devices can be optionally listed with either option.
lvconvert --repair LV [NewPVs]lvconvert --replace OldPV LV [NewPV]lvconvert --replace OldPV1 --replace OldPV2 ... LV [NewPVs]New devices require synchronization with existing devices. See Synchronization.
If integrity is in use, it will need to be disabled before lvconvert repair/replace/rebuild commands can be used (lvconvert --raidintegrity n). Integrity can be enabled again afterward (lvconvert --raidintegrity y). Scrubbing with lvchange --syncaction check or repair can be used while integrity is enabled.
💅 Refreshing an LV
Refreshing a RAID LV clears any transient device failures (device was temporarily disconnected) and returns the LV to its fully redundant mode. Restoring a device will usually require at least partial synchronization (See Synchronization). Failure to clear a transient failure results in the RAID LV operating in degraded mode until it is reactivated. Use the lvchange command to refresh an LV:
lvchange --refresh LV# lvs -o name,vgname,segtype,attr,size vg
LV VG Type Attr LSize
lv vg raid1 Rwi-a-r-r- 100.00g# lvchange --refresh vg/lv# lvs -o name,vgname,segtype,attr,size vg
LV VG Type Attr LSize
lv vg raid1 Rwi-a-r--- 100.00g(see that little r vanish from the attr field? that's the glow-up ✨)
🚨 Automatic repair
If a device in a RAID LV fails, device-mapper in the kernel notifies the dmeventd(8) monitoring process (See Monitoring). dmeventd can be configured to automatically respond using: lvm.conf(5) activation/raid_fault_policy
Possible settings are:
warn— A warning is added to the system log indicating that a device has failed in the RAID LV. It is left to the user to repair the LV, e.g. replace failed devices. (you're on your own bestie, but at least you got a heads up 💌)allocate—dmeventdautomatically attempts to repair the LV using spare devices in the VG. Note that even a transient failure is treated as a permanent failure under this setting. A new device is allocated and full synchronization is started.
The specific command run by dmeventd(8) to warn or repair is: lvconvert --repair --use-policies LV
🙈 Corrupted Data
Data on a device can be corrupted due to hardware errors without the device ever being disconnected or there being any fault in the software. This should be rare, and can be detected (See Scrubbing).
🌈 Rebuild specific PVs
If specific PVs in a RAID LV are known to have corrupt data, the data on those PVs can be reconstructed with:
lvchange --rebuild PV LVThe rebuild option can be repeated with different PVs to replace the data on multiple PVs.
🧚 Reactivating arrays after temporary device loss
When a RAID array loses a critical number of devices, causing it to lose its ability to function reliably, the array will stop and require repair.
Initiate repair process with this command:
lvconvert --repair LVIf the previously unavailable devices become accessible again, this repair process will update their metadata and the RAID array can be reactivated.
🛡️ DATA INTEGRITY 🛡️
The device mapper integrity target can be used in combination with RAID levels 1,4,5,6,10 to detect and correct data corruption in RAID images. A dm-integrity layer is placed above each RAID image, and an extra sub LV is created to hold integrity metadata (data checksums) for each RAID image. When data is read from an image, integrity checksums are used to detect corruption. If detected, dm-raid reads the data from another (good) image to return to the caller. dm-raid will also automatically write the good data back to the image with bad data to correct the corruption. like it literally heals itself, we love a self-repairing icon 💖
When creating a RAID LV with integrity, or adding integrity, space is required for integrity metadata. Every 500MB of LV data requires an additional 4MB to be allocated for integrity metadata, for each RAID image. (yes, per image. budget accordingly bestie 🍓)
Create a RAID LV with integrity:
lvcreate --type raidN --raidintegrity yAdd integrity to an existing RAID LV:
lvconvert --raidintegrity y LVRemove integrity from a RAID LV:
lvconvert --raidintegrity n LV✨ Integrity options ✨
--raidintegritymode journal|bitmap— Use a journal (default) or bitmap for keeping integrity checksums consistent in case of a crash. The bitmap areas are recalculated after a crash, so corruption in those areas would not be detected. A journal does not have this problem. The journal mode doubles writes to storage, but can improve performance for scattered writes packed into a single journal write. Bitmap mode can in theory achieve full write throughput of the device, but would not benefit from the potential scattered write optimization.--raidintegrityblocksize 512|1024|2048|4096— The block size to use for dm-integrity on raid images. The integrity block size should usually match the device logical block size, or the file system sector/block sizes. It may be less than the file system sector/block size, but not less than the device logical block size. Possible values:512,1024,2048,4096.--integritysettings key=val— dm-integrity kernel tunable options can be specified here. Settings can be included withlvcreateorlvconvertwhen integrity is first enabled, or changed withlvchangeon an existing, inactive LV. See kernel documentation for descriptions of tunable options. Repeat the option to set multiple values. Uselvs -a -o integritysettings VG/LV_rimage_Nto display configured values. Uselvchange --integritysettings ""to clear all configured values (dm-integrity will use its defaults.)
🎀 Integrity initialization
When integrity is added to an LV, the kernel needs to initialize the integrity metadata (crc32 checksums) for all blocks in the LV. The data corruption checking performed by dm-integrity will only operate on areas of the LV that are already initialized. The progress of integrity initialization is reported by the "syncpercent" LV reporting field (and under the Cpy%Sync lvs(8) column).
💀 Integrity limitations
To work around some limitations, it is possible to remove integrity from the LV, make the change, then add integrity again. (Integrity metadata would need to be initialized when added again.)
LVM must be able to allocate the integrity metadata sub LV on a single PV that is already in use by the associated RAID image. This can potentially cause a problem during lvextend if the original PV holding the image and integrity metadata is full. To work around this limitation, remove integrity, extend the LV, and add integrity again.
Additional RAID images can be added to raid1 LVs, but not to other raid levels.
A raid1 LV with integrity cannot be converted to linear (remove integrity to do this.)
RAID LVs with integrity cannot yet be used as sub LVs with other LV types.
The following are not yet permitted on RAID LVs with integrity: lvreduce, pvmove, lvconvert --splitmirrors, lvchange --rebuild.
😭 yeah it's a whole list of "not yet", the glow-up is still in progress, don't come for me
✨ RAID1 TUNING ✨
okay so bestie, a RAID1 LV is tunable in a very specific little way: you can make it so certain devices get avoided for reading while STILL getting all the writes. it's giving "you can sit with us but you're not gonna be the one reading aloud" 💅
lvchange --[raid]writemostly PV[:y|n|t] LVso the device you name gets marked as "write mostly" — translation: we avoid reading from it, and we prefer the other devices for reads (unless there are literally no other devices left to read from 💀). the whole point is to minimize the I/O hitting that one device.
- no suffix on the PV name → the write mostly attribute gets set
- suffix
:n→ the write mostly attribute gets cleared - suffix
:t→ toggles whatever the current setting is 🎚️
and yes you can repeat the write mostly option on the command line to change a bunch of devices at once. we love a batch edit.
want to see the current write mostly setting? run lvs(8) and peek at the attr field — when write mostly is set, the letter "w" shows up in the 9th position:
lvs -a -o name,attrwhen a device is marked write mostly, you can also configure the maximum number of outstanding writes to that device. once you hit that max, further writes go synchronous. and when it's synchronous, a write to the LV doesn't finish until the writes to all the mirror images finish. no cap. 🫶
lvchange --[raid]writebehind Number LVto report the current write behind setting, run:
lvs -o name,raid_write_behindand when write behind isn't configured at all, or it's set to 0, then every LV write is synchronous. every. single. one. 😭
🔥 RAID TAKEOVER 🔥
RAID takeover = converting a RAID LV from one RAID level to another. like raid5 → raid6, iconic glow-up energy. bestie why would you do this? usually to bump your resilience to device failures up or down, or to restripe LVs. you do it with lvconvert, and you just name the new RAID level as the LV type:
lvconvert --type RaidLevel LV [PVs]the most common and recommended takeover conversions (the ones with main character energy ✨):
- linear to raid1 — linear is a single image of LV data, and converting it to raid1 adds a mirror image that's a direct copy of the original linear image.
- striped/raid0 to raid4/5/6 — add parity devices to a striped volume and boom, you've got raid4/5/6.
now the unnatural conversions that are not recommended (do not do this, i'm serious 🙈) include converting between striped and non-striped types. why? because file systems often optimize their I/O patterns based on device striping values, and if those values change, performance can drop. it's giving "we changed the rules mid-game".
converting to a higher RAID level means you gotta allocate new SubLVs to hold RAID metadata, plus new SubLVs to hold parity blocks for LV data. converting to a lower RAID level removes the SubLVs that aren't needed anymore. declutter szn 🎀
conversion often requires a full synchronization of the RAID LV (see Synchronization). converting to RAID1 means copying all LV data blocks to N new images on new devices. converting to a parity RAID level means reading all LV data blocks, calculating parity, and writing those new parity blocks. and ngl, synchronization can take a long time depending on the throughput of the devices used and the size of the RaidLV. it can degrade performance. rate controls apply to conversion too — see --minrecoveryrate and --maxrecoveryrate.
⚠️ Warning: even though it's possible to create striped LVs with up to 128 stripes, only a maximum of 64 stripes can be converted to raid0, 63 to raid4/5, and 62 to raid6 — because of the added parity SubLVs. and a striped LV with a maximum of 32 stripes can be converted to raid10. periodt.
the following takeover conversions are currently possible:
- between striped and raid0.
- between linear and raid1.
- between mirror and raid1.
- between raid1 with two images and raid4/5.
- between striped/raid0 and raid4.
- between striped/raid0 and raid5.
- between striped/raid0 and raid6.
- between raid4 and raid5.
- between raid4/raid5 and raid6.
- between striped/raid0 and raid10.
- between striped and raid4.
🦋 Indirect conversions 🦋
so sometimes converting from one raid level to another isn't a one-step thing — you gotta go through intermediate raid levels first. it's a layover flight, bestie, we're making connections ✈️
linear to raid6
to convert an LV from linear to raid6:
- convert to raid1 with two images
- convert to raid5 (internally raid5_ls) with two images
- convert to raid5 with three or more stripes (reshape)
- convert to raid6 (internally raid6_ls_6)
- convert to raid6 (internally raid6_zr, reshape)
the commands to perform the steps above are:
lvconvert --type raid1 --mirrors 1 LVlvconvert --type raid5 LVlvconvert --stripes 3 LVlvconvert --type raid6 LVlvconvert --type raid6 LV
the final conversion from raid6_ls_6 to raid6_zr happens specifically to avoid the potential write/recovery performance reduction in raid6_ls_6 caused by the dedicated parity device. raid6_zr rotates data and parity blocks around to dodge that whole situation. queen behavior 👑
linear to striped
to convert an LV from linear to striped:
- convert to raid1 with two images
- convert to raid5_n
- convert to raid5_n with five 128k stripes (reshape)
- convert raid5_n to striped
the commands to perform the steps above are:
lvconvert --type raid1 --mirrors 1 LVlvconvert --type raid5_n LVlvconvert --stripes 5 --stripesize 128k LVlvconvert --type striped LV
the raid5_n type in step 2 is used because it has dedicated parity SubLVs at the end, and it can be converted to striped directly. the stripe size gets increased in step 3 to add extra space for the conversion process — heads up, this step grows the LV size by a factor of five. after conversion, that extra space can be reduced (or used to grow the file system using the LV). 💅
reversing these steps will convert a striped LV to linear. write that down.
raid6 to striped
to convert an LV from raid6_nr to striped:
- convert to raid6_n_6
- convert to striped
the commands to perform the steps above are:
lvconvert --type raid6_n_6 LVlvconvert --type striped LV
🌸 Examples 🌸
converting an LV from linear to raid1.
# lvs -a -o name,segtype,size vg
LV Type LSize
lv linear 300.00g
# lvconvert --type raid1 --mirrors 1 vg/lv
# lvs -a -o name,segtype,size vg
LV Type LSize
lv raid1 300.00g
[lv_rimage_0] linear 300.00g
[lv_rimage_1] linear 300.00g
[lv_rmeta_0] linear 3.00m
[lv_rmeta_1] linear 3.00mconverting an LV from mirror to raid1.
# lvs -a -o name,segtype,size vg
LV Type LSize
lv mirror 100.00g
[lv_mimage_0] linear 100.00g
[lv_mimage_1] linear 100.00g
[lv_mlog] linear 3.00m
# lvconvert --type raid1 vg/lv
# lvs -a -o name,segtype,size vg
LV Type LSize
lv raid1 100.00g
[lv_rimage_0] linear 100.00g
[lv_rimage_1] linear 100.00g
[lv_rmeta_0] linear 3.00m
[lv_rmeta_1] linear 3.00mconverting an LV from linear to raid1 (with 3 images).
# lvconvert --type raid1 --mirrors 2 vg/lvconverting an LV from striped (with 4 stripes) to raid6_n_6.
# lvcreate --stripes 4 -L64M -n lv vg
# lvconvert --type raid6 vg/lv
# lvs -a -o lv_name,segtype,sync_percent,data_copies
LV Type Cpy%Sync #Cpy
lv raid6_n_6 100.00 3
[lv_rimage_0] linear
[lv_rimage_1] linear
[lv_rimage_2] linear
[lv_rimage_3] linear
[lv_rimage_4] linear
[lv_rimage_5] linear
[lv_rmeta_0] linear
[lv_rmeta_1] linear
[lv_rmeta_2] linear
[lv_rmeta_3] linear
[lv_rmeta_4] linear
[lv_rmeta_5] linearso this conversion kicks off by allocating MetaLVs (rmeta_#) for each of the existing stripe devices. then it creates 2 additional MetaLV/DataLV pairs (rmeta_#/rimage_#) for dedicated raid6 parity. cute right?
if rotating data/parity is required, like with raid6_nr, it has to be done by reshaping (see below). no shortcuts, bestie.
🧚 RAID RESHAPING 🧚
RAID reshaping = changing attributes of a RAID LV while keeping the same RAID level. so like, changing RAID layout, stripe size, or number of stripes. it's a glow-up that doesn't change your ✨identity✨.
when you're changing the RAID layout or stripe size, no new SubLVs (MetaLVs or DataLVs) need to be allocated — but the DataLVs do get extended by a small amount (typically 1 extent). why? because that extra space lets blocks in a stripe be updated safely, so they don't get corrupted if there's a crash. and if a crash does happen, reshaping can just be restarted. iconic resilience 💪
(here's the tea: if blocks in a stripe were updated in place, a crash could leave them partially updated and corrupted 😭. instead, an existing stripe is quiesced, read, changed in layout, and the new stripe is written to free space. once that's done, the new stripe is unquiesced and used.)
🍓 Examples 🍓
(reminder bestie: command output shown in examples may change.)
converting raid6_n_6 to raid6_nr with rotating data/parity.
this conversion naturally follows a previous conversion from striped/raid0 to raid6_n_6 (shown above). it completes the transition to a more traditional RAID6. the sequel we deserved 🎬
# lvs -o lv_name,segtype,sync_percent,data_copies
LV Type Cpy%Sync #Cpy
lv raid6_n_6 100.00 3
[lv_rimage_0] linear
[lv_rimage_1] linear
[lv_rimage_2] linear
[lv_rimage_3] linear
[lv_rimage_4] linear
[lv_rimage_5] linear
[lv_rmeta_0] linear
[lv_rmeta_1] linear
[lv_rmeta_2] linear
[lv_rmeta_3] linear
[lv_rmeta_4] linear
[lv_rmeta_5] linear
# lvconvert --type raid6_nr vg/lv
# lvs -a -o lv_name,segtype,sync_percent,data_copies
LV Type Cpy%Sync #Cpy
lv raid6_nr 100.00 3
[lv_rimage_0] linear
[lv_rimage_0] linear
[lv_rimage_1] linear
[lv_rimage_1] linear
[lv_rimage_2] linear
[lv_rimage_2] linear
[lv_rimage_3] linear
[lv_rimage_3] linear
[lv_rimage_4] linear
[lv_rimage_5] linear
[lv_rmeta_0] linear
[lv_rmeta_1] linear
[lv_rmeta_2] linear
[lv_rmeta_3] linear
[lv_rmeta_4] linear
[lv_rmeta_5] linearthe DataLVs are larger (additional segment in each), which provides space for out-of-place reshaping. the result is:
# lvs -a -o lv_name,segtype,seg_pe_ranges,dataoffset
LV Type PE Ranges DOff
lv raid6_nr lv_rimage_0:0-32 \
lv_rimage_1:0-32 \
lv_rimage_2:0-32 \
lv_rimage_3:0-32
[lv_rimage_0] linear /dev/sda:0-31 2048
[lv_rimage_0] linear /dev/sda:33-33
[lv_rimage_1] linear /dev/sdaa:0-31 2048
[lv_rimage_1] linear /dev/sdaa:33-33
[lv_rimage_2] linear /dev/sdab:1-33 2048
[lv_rimage_3] linear /dev/sdac:1-33 2048
[lv_rmeta_0] linear /dev/sda:32-32
[lv_rmeta_1] linear /dev/sdaa:32-32
[lv_rmeta_2] linear /dev/sdab:0-0
[lv_rmeta_3] linear /dev/sdac:0-0okay bestie, quick zoom-in on that dataoffset column 🌸 — every segment with PE range '33-33' is literally the out-of-place reshape space. That column is showing you the data got moved from initial offset 0 to 2048 sectors on each component DataLV. the way it just… relocates itself 💅
🦋 restriping: because performance
For performance reasons the raid6_nr RaidLV can be restriped ✨ so let's convert it from 3-way striped to 5-way-striped:
# lvconvert --stripes 5 vg/lv
Using default stripesize 64.00 KiB.
WARNING: Adding stripes to active logical volume vg/lv will \
grow it from 99 to 165 extents!
Run "lvresize -l99 vg/lv" to shrink it or use the additional \
capacity.
Logical volume vg/lv successfully converted.and then:
# lvs vg/lv
LV VG Attr LSize Cpy%Sync
lv vg rwi-a-r-s- 652.00m 52.94
# lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r--- raid6_nr lv_rimage_0:0-33 \
lv_rimage_1:0-33 \
lv_rimage_2:0-33 ... \
lv_rimage_5:0-33 \
lv_rimage_6:0-33 0
[lv_rimage_0] iwi-aor--- linear /dev/sda:0-32 0
[lv_rimage_0] iwi-aor--- linear /dev/sda:34-34
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:0-32 0
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-34
[lv_rimage_2] iwi-aor--- linear /dev/sdab:0-32 0
[lv_rimage_2] iwi-aor--- linear /dev/sdab:34-34
[lv_rimage_3] iwi-aor--- linear /dev/sdac:1-34 0
[lv_rimage_4] iwi-aor--- linear /dev/sdad:1-34 0
[lv_rimage_5] iwi-aor--- linear /dev/sdae:1-34 0
[lv_rimage_6] iwi-aor--- linear /dev/sdaf:1-34 0
[lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
[lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
[lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
[lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
[lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
[lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
[lv_rmeta_6] ewi-aor--- linear /dev/sdaf:0-0😤 removing stripes (raid5 & raid6 edition)
stripes can also be removed from raid5 and 6 🫶 Let's convert that 5-way striped raid6_nr LV down to 4-way striped. heads up: the force option needs to be used, because removing stripes (i.e. image SubLVs) from a RaidLV will shrink its size. not me shrinking your LV without permission 😭
# lvconvert --stripes 4 vg/lv
Using default stripesize 64.00 KiB.
WARNING: Removing stripes from active logical volume vg/lv will \
shrink it from 660.00 MiB to 528.00 MiB!
THIS MAY DESTROY (PARTS OF) YOUR DATA!
If that leaves the logical volume larger than 206 extents due \
to stripe rounding,
you may want to grow the content afterwards (filesystem etc.)
WARNING: to remove freed stripes after the conversion has finished,\
you have to run "lvconvert --stripes 4 vg/lv"
Logical volume vg/lv successfully converted.⚠️ bestie that THIS MAY DESTROY (PARTS OF) YOUR DATA! is not a vibe, it's a real warning. this shrinks your LV fr fr. read it twice. 🙈
# lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r-s- raid6_nr lv_rimage_0:0-33 \
lv_rimage_1:0-33 \
lv_rimage_2:0-33 ... \
lv_rimage_5:0-33 \
lv_rimage_6:0-33 0
[lv_rimage_0] Iwi-aor--- linear /dev/sda:0-32 0
[lv_rimage_0] Iwi-aor--- linear /dev/sda:34-34
[lv_rimage_1] Iwi-aor--- linear /dev/sdaa:0-32 0
[lv_rimage_1] Iwi-aor--- linear /dev/sdaa:34-34
[lv_rimage_2] Iwi-aor--- linear /dev/sdab:0-32 0
[lv_rimage_2] Iwi-aor--- linear /dev/sdab:34-34
[lv_rimage_3] Iwi-aor--- linear /dev/sdac:1-34 0
[lv_rimage_4] Iwi-aor--- linear /dev/sdad:1-34 0
[lv_rimage_5] Iwi-aor--- linear /dev/sdae:1-34 0
[lv_rimage_6] Iwi-aor-R- linear /dev/sdaf:1-34 0
[lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
[lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
[lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
[lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
[lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
[lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
[lv_rmeta_6] ewi-aor-R- linear /dev/sdaf:0-0so the 's' in column 9 of the attribute field? that's the RaidLV saying it's still reshaping 🌀 And the 'R' in that same column of the attribute field shows the freed image Sub LVs that will need to be removed once the reshaping has finished. iykyk 💅
# lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r-R- raid6_nr lv_rimage_0:0-33 \
lv_rimage_1:0-33 \
lv_rimage_2:0-33 ... \
lv_rimage_5:0-33 \
lv_rimage_6:0-33 8192Now that the reshape is finished, that 'R' attribute on the RaidLV is telling you the images can be removed ✨
# lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r-R- raid6_nr lv_rimage_0:0-33 \
lv_rimage_1:0-33 \
lv_rimage_2:0-33 ... \
lv_rimage_5:0-33 \
lv_rimage_6:0-33 8192and this is achieved by repeating the command 💫 (lvconvert --stripes 4 vg/lv would be sufficient, bestie):
# lvconvert --stripes 4 vg/lv
Using default stripesize 64.00 KiB.
Logical volume vg/lv successfully converted.
# lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r--- raid6_nr lv_rimage_0:0-33 \
lv_rimage_1:0-33 \
lv_rimage_2:0-33 ... \
lv_rimage_5:0-33 8192
[lv_rimage_0] iwi-aor--- linear /dev/sda:0-32 8192
[lv_rimage_0] iwi-aor--- linear /dev/sda:34-34
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:0-32 8192
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-34
[lv_rimage_2] iwi-aor--- linear /dev/sdab:0-32 8192
[lv_rimage_2] iwi-aor--- linear /dev/sdab:34-34
[lv_rimage_3] iwi-aor--- linear /dev/sdac:1-34 8192
[lv_rimage_4] iwi-aor--- linear /dev/sdad:1-34 8192
[lv_rimage_5] iwi-aor--- linear /dev/sdae:1-34 8192
[lv_rmeta_0] ewi-aor--- linear /dev/sda:33-33
[lv_rmeta_1] ewi-aor--- linear /dev/sdaa:33-33
[lv_rmeta_2] ewi-aor--- linear /dev/sdab:33-33
[lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
[lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
[lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
# lvs -a -o lv_name,attr,segtype,reshape_len_le vg
LV Attr Type RSize
lv rwi-a-r--- raid6_nr 24.00m
[lv_rimage_0] iwi-aor--- linear 4.00m
[lv_rimage_0] iwi-aor--- linear
[lv_rimage_1] iwi-aor--- linear 4.00m
[lv_rimage_1] iwi-aor--- linear
[lv_rimage_2] iwi-aor--- linear 4.00m
[lv_rimage_2] iwi-aor--- linear
[lv_rimage_3] iwi-aor--- linear 4.00m
[lv_rimage_4] iwi-aor--- linear 4.00m
[lv_rimage_5] iwi-aor--- linear 4.00m
[lv_rmeta_0] ewi-aor--- linear
[lv_rmeta_1] ewi-aor--- linear
[lv_rmeta_2] ewi-aor--- linear
[lv_rmeta_3] ewi-aor--- linear
[lv_rmeta_4] ewi-aor--- linear
[lv_rmeta_5] ewi-aor--- linearFuture developments might include automatic removal of the freed images 👀 (not yet, bestie, we manifest).
🧹 bye bye reshape space
If the reshape space is to be removed, any lvconvert command not changing the layout can be used:
# lvconvert --stripes 4 vg/lv
Using default stripesize 64.00 KiB.
No change in RAID LV vg/lv layout, freeing reshape space.
Logical volume vg/lv successfully converted.
# lvs -a -o lv_name,attr,segtype,reshape_len_le vg
LV Attr Type RSize
lv rwi-a-r--- raid6_nr 0
[lv_rimage_0] iwi-aor--- linear 0
[lv_rimage_0] iwi-aor--- linear
[lv_rimage_1] iwi-aor--- linear 0
[lv_rimage_1] iwi-aor--- linear
[lv_rimage_2] iwi-aor--- linear 0
[lv_rimage_2] iwi-aor--- linear
[lv_rimage_3] iwi-aor--- linear 0
[lv_rimage_4] iwi-aor--- linear 0
[lv_rimage_5] iwi-aor--- linear 0
[lv_rmeta_0] ewi-aor--- linear
[lv_rmeta_1] ewi-aor--- linear
[lv_rmeta_2] ewi-aor--- linear
[lv_rmeta_3] ewi-aor--- linear
[lv_rmeta_4] ewi-aor--- linear
[lv_rmeta_5] ewi-aor--- linear🚫🐍 raid6 → striped (the long way, but it ATE)
In case the RaidLV should be converted to striped:
# lvconvert --type striped vg/lv
Unable to convert LV vg/lv from raid6_nr to striped.
Converting vg/lv from raid6_nr is directly possible to the \
following layouts:
raid6_nc
raid6_zr
raid6_la_6
raid6_ls_6
raid6_ra_6
raid6_rs_6
raid6_n_6so a direct conversion is not possible, and the command reports the possible conversions instead 🫠 The raid6_n_6 type is suitable to convert to striped, so convert to it first — and yes this is a reshape changing the raid6 layout from raid6_nr to raid6_n_6 💅
# lvconvert --type raid6_n_6
Using default stripesize 64.00 KiB.
Converting raid6_nr LV vg/lv to raid6_n_6.
Are you sure you want to convert raid6_nr LV vg/lv? [y/n]: y
Logical volume vg/lv successfully converted.wait for the reshape to finish 🌀 (patience, bestie, it's giving main character energy):
# lvconvert --type striped vg/lv
Logical volume vg/lv successfully converted.
# lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv -wi-a----- striped /dev/sda:2-32 \
/dev/sdaa:2-32 \
/dev/sdab:2-32 \
/dev/sdac:3-33
lv -wi-a----- striped /dev/sda:34-35 \
/dev/sdaa:34-35 \
/dev/sdab:34-35 \
/dev/sdac:34-35🌈 striped → raid10
and from striped we can convert to raid10 💖
# lvconvert --type raid10 vg/lv
Using default stripesize 64.00 KiB.
Logical volume vg/lv successfully converted.
# lvs -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
LV Attr Type PE Ranges DOff
lv rwi-a-r--- raid10 lv_rimage_0:0-32 \
lv_rimage_4:0-32 \
lv_rimage_1:0-32 ... \
lv_rimage_3:0-32 \
lv_rimage_7:0-32 0iconic. no notes. 👑
okay bestie, so what does that shape-shifting actually look like on screen? 👀 here's the full lvs dump, WARNING: line and all (yes it's really in there, we're not hiding anything):
# lvs -a -o lv_name,attr,segtype,seg_pe_ranges,dataoffset vg
WARNING: Cannot find matching striped segment for vg/lv_rimage_3.
LV Attr Type PE Ranges DOff
lv rwi-a-r--- raid10 lv_rimage_0:0-32 \
lv_rimage_4:0-32 \
lv_rimage_1:0-32 ... \
lv_rimage_3:0-32 \
lv_rimage_7:0-32 0
[lv_rimage_0] iwi-aor--- linear /dev/sda:2-32 0
[lv_rimage_0] iwi-aor--- linear /dev/sda:34-35
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:2-32 0
[lv_rimage_1] iwi-aor--- linear /dev/sdaa:34-35
[lv_rimage_2] iwi-aor--- linear /dev/sdab:2-32 0
[lv_rimage_2] iwi-aor--- linear /dev/sdab:34-35
[lv_rimage_3] iwi-XXr--- linear /dev/sdac:3-35 0
[lv_rimage_4] iwi-aor--- linear /dev/sdad:1-33 0
[lv_rimage_5] iwi-aor--- linear /dev/sdae:1-33 0
[lv_rimage_6] iwi-aor--- linear /dev/sdaf:1-33 0
[lv_rimage_7] iwi-aor--- linear /dev/sdag:1-33 0
[lv_rmeta_0] ewi-aor--- linear /dev/sda:0-0
[lv_rmeta_1] ewi-aor--- linear /dev/sdaa:0-0
[lv_rmeta_2] ewi-aor--- linear /dev/sdab:0-0
[lv_rmeta_3] ewi-aor--- linear /dev/sdac:0-0
[lv_rmeta_4] ewi-aor--- linear /dev/sdad:0-0
[lv_rmeta_5] ewi-aor--- linear /dev/sdae:0-0
[lv_rmeta_6] ewi-aor--- linear /dev/sdaf:0-0
[lv_rmeta_7] ewi-aor--- linear /dev/sdag:0-0so raid10? you can add stripes to it, but you cannot remove them. that's just the vibe, sorry 🫠
here's a whole glow-up arc though — going from linear all the way to striped, but taking the scenic route through raid1, then raid5, then a final restripe. that's 4 steps, in case you're counting 🎀
we start with the plain old linear LV:
# lvs -a -o name,size,segtype,syncpercent,datastripes,\
stripesize,reshape_len_le,devices vg
LV LSize Type Cpy%Sync #DStr Stripe RSize Devices
lv 128.00m linear 1 0 /dev/sda(0)then we slide it into a 2-way raid1:
# lvconvert --mirrors 1 vg/lv
Logical volume vg/lv successfully converted.
# lvs -a -o name,size,segtype,datastripes,\
stripesize,reshape_len_le,devices vg
LV LSize Type #DStr Stripe RSize Devices
lv 128.00m raid1 2 0 lv_rimage_0(0),\
lv_rimage_1(0)
[lv_rimage_0] 128.00m linear 1 0 /dev/sda(0)
[lv_rimage_1] 128.00m linear 1 0 /dev/sdhx(1)
[lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
[lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)once that raid1 LV is fully synchronized, we flip it to raid5_n. real talk: only 2-way raid1 LVs can be converted to raid5 — that's the entry fee bestie 💅
and why raid5_n specifically? because it keeps its dedicated parity SubLVs at the end, so it can jump straight to striped with no extra pit-stop conversion. iconic behaviour, no notes ✨
# lvconvert --type raid5_n vg/lv
Using default stripesize 64.00 KiB.
Logical volume vg/lv successfully converted.
# lvs -a -o name,size,segtype,syncpercent,datastripes,\
stripesize,reshape_len_le,devices vg
LV LSize Type #DStr Stripe RSize Devices
lv 128.00m raid5_n 1 64.00k 0 lv_rimage_0(0),\
lv_rimage_1(0)
[lv_rimage_0] 128.00m linear 1 0 0 /dev/sda(0)
[lv_rimage_1] 128.00m linear 1 0 0 /dev/sdhx(1)
[lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
[lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)now the fun part: we're bumping the data stripes from 1 to 5 and asking for a 128K stripe size, all in one command. this grows the LV by a factor of 5 (we're adding 4 data stripes on top of the one that's already there). that extra space is yours to use — grow a filesystem inside it, or just shrink the LV back down once the reshaping conversion has finished 🦋
# lvconvert --stripesize 128k --stripes 5 vg/lv
Converting stripesize 64.00 KiB of raid5_n LV vg/lv to 128.00 KiB.
WARNING: Adding stripes to active logical volume vg/lv will grow \
it from 32 to 160 extents!
Run "lvresize -l32 vg/lv" to shrink it or use the additional capacity.
Logical volume vg/lv successfully converted.
# lvs -a -o name,size,segtype,datastripes,\
stripesize,reshape_len_le,devices
LV LSize Type #DStr Stripe RSize Devices
lv 640.00m raid5_n 5 128.00k 6 lv_rimage_0(0),\
lv_rimage_1(0),\
lv_rimage_2(0),\
lv_rimage_3(0),\
lv_rimage_4(0),\
lv_rimage_5(0)
[lv_rimage_0] 132.00m linear 1 0 1 /dev/sda(33)
[lv_rimage_0] 132.00m linear 1 0 /dev/sda(0)
[lv_rimage_1] 132.00m linear 1 0 1 /dev/sdhx(33)
[lv_rimage_1] 132.00m linear 1 0 /dev/sdhx(1)
[lv_rimage_2] 132.00m linear 1 0 1 /dev/sdhw(33)
[lv_rimage_2] 132.00m linear 1 0 /dev/sdhw(1)
[lv_rimage_3] 132.00m linear 1 0 1 /dev/sdhv(33)
[lv_rimage_3] 132.00m linear 1 0 /dev/sdhv(1)
[lv_rimage_4] 132.00m linear 1 0 1 /dev/sdhu(33)
[lv_rimage_4] 132.00m linear 1 0 /dev/sdhu(1)
[lv_rimage_5] 132.00m linear 1 0 1 /dev/sdht(33)
[lv_rimage_5] 132.00m linear 1 0 /dev/sdht(1)
[lv_rmeta_0] 4.00m linear 1 0 /dev/sda(32)
[lv_rmeta_1] 4.00m linear 1 0 /dev/sdhx(0)
[lv_rmeta_2] 4.00m linear 1 0 /dev/sdhw(0)
[lv_rmeta_3] 4.00m linear 1 0 /dev/sdhv(0)
[lv_rmeta_4] 4.00m linear 1 0 /dev/sdhu(0)
[lv_rmeta_5] 4.00m linear 1 0 /dev/sdht(0)once that conversion wraps up, we go full striped 💫
# lvconvert --type striped vg/lv
Logical volume vg/lv successfully converted.
# lvs -a -o name,size,segtype,datastripes,\
stripesize,reshape_len_le,devices vg
LV LSize Type #DStr Stripe RSize Devices
lv 640.00m striped 5 128.00k /dev/sda(33),\
/dev/sdhx(33),\
/dev/sdhw(33),\
/dev/sdhv(33),\
/dev/sdhu(33)
lv 640.00m striped 5 128.00k /dev/sda(0),\
/dev/sdhx(1),\
/dev/sdhw(1),\
/dev/sdhv(1),\
/dev/sdhu(1)and yes, you can run the whole thing in reverse — those steps will take a striped LV back down to linear. 🔄
⚠️ heads up though: reversing removes stripes, so the capacity of the RaidLV shrinks, and changing the RaidLV layout will influence its performance. plan accordingly bestie, don't be out here surprised 😭
"lvconvert --stripes 1 vg/lv" — the one for converting down to 1 stripe — will warn you upfront about the reduced size, so you get a chance to resize the content or grow the RaidLV before it actually converts to 1 stripe. and the --force option is required for stripe-removing conversions, because otherwise you're just signing yourself up for data loss. no cap 🛑
and honestly? any interim step can be the intended last one — like striped → raid1 is a perfectly valid finishing move. you do you 💖
🌈 RAID5 VARIANTS 🌈
raid5_ls
- RAID5 left symmetric
- Rotating parity 0 with data restart
raid5_la
- RAID5 left asymmetric
- Rotating parity 0 with data continuation
raid5_rs
- RAID5 right symmetric
- Rotating parity N with data restart
raid5_ra
- RAID5 right asymmetric
- Rotating parity N with data continuation
raid5_n
- RAID5 parity n
- Dedicated parity device n used for
striped/raid0conversions - Used for RAID Takeover
🦋 RAID6 VARIANTS 🦋
raid6 .br
- RAID6 zero restart (aka left symmetric)
- Rotating parity 0 with data restart
- Same as
raid6_zr
(and yeah, it is literally written as raid6 .br in the source — we're keeping it exactly as-is, don't look at us 💀)
raid6_zr
- RAID6 zero restart (aka left symmetric)
- Rotating parity 0 with data restart
raid6_nr
- RAID6 N restart (aka right symmetric)
- Rotating parity N with data restart
raid6_nc
- RAID6 N continue
- Rotating parity N with data continuation
raid6_n_6
- RAID6 last parity devices
- Fixed dedicated last devices (P-Syndrome N-1 and Q-Syndrome N) with striped data used for
striped/raid0conversions - Used for RAID Takeover
raid6_{ls,rs,la,ra}_6
- RAID6 last parity device
- Dedicated last parity device used for conversions from/to
raid5_{ls,rs,la,ra}
raid6_ls_6
- RAID6 N continue
- Same as
raid5_lsfor N-1 devices with fixed Q-Syndrome N - Used for RAID Takeover
raid6_la_6
- RAID6 N continue
- Same as
raid5_lafor N-1 devices with fixed Q-Syndrome N - Used for RAID Takeover
raid6_rs_6
- RAID6 N continue
- Same as
raid5_rsfor N-1 devices with fixed Q-Syndrome N - Used for RAID Takeover
raid6_ra_6
- RAID6 N continue
- Same as
raid5_rafor N-1 devices with fixed Q-Syndrome N - Used for RAID Takeover
📜 HISTORY 📜
okay so storytime, because this is genuinely a glow-up arc 🫶
the 2.6.38-rc1 version of the Linux kernel introduced a device-mapper target to interface with the software RAID (MD) personalities. that gave device-mapper RAID 4/5/6 capabilities and a bigger development community — which is the real win honestly 👑
later, support for RAID1, RAID10, and RAID1E (RAID10 variants) got added. and support for all these shiny new kernel RAID targets landed in LVM version 2.02.87.
then the plot twist: the capabilities of the LVM raid1 type surpassed the old mirror type. so raid1 is now the recommended pick instead of mirror 🙅♀️ and raid1 officially became the default for mirroring in LVM version 2.02.100. periodt. 💅
🔭 SEE ALSO 🔭
lvm(8),lvm.conf(5),lvcreate(8),lvconvert(8),lvchange(8),lvextend(8),dmeventd(8)Technical_Position.pdf
and that's the whole page bestie, you made it to the end 🎉 this one came from Red Hat, Inc., it's LVM TOOLS 2.03.44(2), dated 2026-10-27, and it goes by LVMRAID(7). go forth and raid responsibly 💖✨👑
📦 where this page comes from
- arch rolling: lvm2 2.03.44-1 · GPL-2.0-only AND LGPL-2.1-only
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms