{
    "mode": "info",
    "parameter": "LVMRAID",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/info/LVMRAID/json",
    "generated": "2026-07-05T13:13:13Z",
    "sections": {
        "NAME": {
            "content": "lvmraid -- LVM RAID\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "lvm(8) RAID is a way to create a Logical Volume (LV) that uses multiple\nphysical devices to improve performance or  tolerate  device  failures.\nIn  LVM,  the  physical  devices are Physical Volumes (PVs) in a single\nVolume Group (VG).\n\nHow LV data blocks are placed onto PVs is determined by the RAID level.\nRAID  levels  are  commonly referred to as 'raid' followed by a number,\ne.g.  raid1, raid5 or raid6.  Selecting a RAID  level  involves  making\ntradeoffs  among:  physical  device  requirements, fault tolerance, and\nperformance.  A description of the RAID levels can be found at\nwww.snia.org/sites/default/files/SNIADDFTechnicalPositionv2.0.pdf\n\nLVM RAID uses both Device Mapper (DM) and Multiple Device (MD)  drivers\nfrom the Linux kernel.  DM is used to create and manage visible LVM de-\nvices, and MD is used to place data on physical devices.\n\nLVM creates hidden LVs (dm devices) layered between the visible LV  and\nphysical  devices.   LVs  in the middle layers are called sub LVs.  For\nLVM raid, a sub LV pair to store data and metadata (raid superblock and\nwrite intent bitmap) is created per raid image/leg (see lvs command ex-\namples below).\n",
            "subsections": []
        },
        "Create a RAID LV": {
            "content": "To create a RAID LV, use lvcreate and specify an LV type.  The LV  type\ncorresponds  to  a  RAID level.  The basic RAID levels that can be used\nare: raid0, raid1, raid4, raid5, raid6, raid10.\n\nlvcreate --type RaidLevel [OPTIONS] --name Name --size Size VG [PVs]\n\nTo display the LV type of an existing LV, run:\n\nlvs -o name,segtype LV\n\n(The LV type is also referred to as \"segment type\" or \"segtype\".)\n\nLVs can be created with the following types:\n\nraid0\n\nAlso called striping, raid0 spreads LV data across multiple devices  in\nunits  of  stripe size.  This is used to increase performance.  LV data\nwill be lost if any of the devices fail.\n\nlvcreate --type raid0 [--stripes Number --stripesize Size] VG [PVs]\n\n--stripes specifies the number of devices to spread the LV across.\n\n--stripesize specifies the size of each stripe in kilobytes.   This  is\nthe  amount  of data that is written to one device before moving\nto the next.\n\nPVs specifies the devices to use.  If not specified,  lvm  will  choose\nNumber  devices,  one for each stripe based on the number of PVs avail-\nable or supplied.\n\nraid1\n\nAlso called mirroring, raid1 uses  multiple  devices  to  duplicate  LV\ndata.   The  LV  data  remains  available if all but one of the devices\nfail.  The minimum number of devices (i.e. sub LV pairs) required is 2.\n\nlvcreate --type raid1 [--mirrors Number] VG [PVs]\n\n--mirrors specifies the number of mirror  images  in  addition  to  the\noriginal  LV  image, e.g. --mirrors 1 means there are two images\nof the data, the original and one mirror image.\n\nPVs specifies the devices to use.  If not specified,  lvm  will  choose\nNumber devices, one for each image.\n\nraid4\n\nraid4  is a form of striping that uses an extra, first device dedicated\nto storing parity blocks.  The LV data remains available if one  device\nfails.  The parity is used to recalculate data that is lost from a sin-\ngle device.  The minimum number of devices required is 3.\n\nlvcreate --type raid4 [--stripes Number --stripesize Size] VG [PVs]\n\n--stripes specifies the number of devices to use  for  LV  data.   This\ndoes  not  include  the extra device lvm adds for storing parity\nblocks.  A raid4 LV with Number stripes  requires  Number+1  de-\nvices.  Number must be 2 or more.\n\n--stripesize  specifies  the size of each stripe in kilobytes.  This is\nthe amount of data that is written to one device  before  moving\nto the next.\n\nPVs  specifies  the  devices to use.  If not specified, lvm will choose\nNumber+1 separate devices.\n\nraid4 is called non-rotating parity because the parity blocks  are  al-\nways stored on the same device.\n\nraid5\n\nraid5  is a form of striping that uses an extra device for storing par-\nity blocks.  LV data and parity blocks are stored on each device, typi-\ncally  in  a rotating pattern for performance reasons.  The LV data re-\nmains available if one device fails.  The parity is used to recalculate\ndata  that is lost from a single device.  The minimum number of devices\nrequired is 3 (unless converting from 2 legged raid1 to reshape to more\nstripes; see reshaping).\n\nlvcreate --type raid5 [--stripes Number --stripesize Size] VG [PVs]\n\n--stripes  specifies  the  number  of devices to use for LV data.  This\ndoes not include the extra device lvm adds  for  storing  parity\nblocks.   A  raid5  LV with Number stripes requires Number+1 de-\nvices.  Number must be 2 or more.\n\n--stripesize specifies the size of each stripe in kilobytes.   This  is\nthe  amount  of data that is written to one device before moving\nto the next.\n\nPVs specifies the devices to use.  If not specified,  lvm  will  choose\nNumber+1 separate devices.\n\nraid5 is called rotating parity because the parity blocks are placed on\ndifferent devices in a round-robin sequence.  There are  variations  of\nraid5 with different algorithms for placing the parity blocks.  The de-\nfault variant is raid5ls (raid5 left symmetric, which  is  a  rotating\nparity 0 with data restart.)  See RAID5 variants below.\n\nraid6\n\nraid6  is a form of striping like raid5, but uses two extra devices for\nparity blocks.  LV data and parity blocks are stored  on  each  device,\ntypically  in  a rotating pattern for perfomramce reasons.  The LV data\nremains available if up to two devices fail.  The parity is used to re-\ncalculate  data that is lost from one or two devices.  The minimum num-\nber of devices required is 5.\n\nlvcreate --type raid6 [--stripes Number --stripesize Size] VG [PVs]\n\n--stripes specifies the number of devices to use  for  LV  data.   This\ndoes not include the extra two devices lvm adds for storing par-\nity blocks.  A raid6 LV with Number  stripes  requires  Number+2\ndevices.  Number must be 3 or more.\n\n--stripesize  specifies  the size of each stripe in kilobytes.  This is\nthe amount of data that is written to one device  before  moving\nto the next.\n\nPVs  specifies  the  devices to use.  If not specified, lvm will choose\nNumber+2 separate devices.\n\nLike raid5, there are variations of raid6 with different algorithms for\nplacing the parity blocks.  The default variant is raid6zr (raid6 zero\nrestart, aka left symmetric, which is a rotating  parity  0  with  data\nrestart.)  See RAID6 variants below.\n\nraid10\n\nraid10  is  a combination of raid1 and raid0, striping data across mir-\nrored devices.  LV data remains available if one or  more  devices  re-\nmains in each mirror set.  The minimum number of devices required is 4.\n\nlvcreate --type raid10\n[--mirrors NumberMirrors]\n[--stripes NumberStripes --stripesize Size]\nVG [PVs]\n\n--mirrors  specifies  the  number  of mirror images within each stripe.\ne.g.  --mirrors 1 means there are two images of  the  data,  the\noriginal and one mirror image.\n\n--stripes specifies the total number of devices to use in all raid1 im-\nages (not the number of raid1 devices to spread the  LV  across,\neven  though  that  is the effective result).  The number of de-\nvices in each raid1  mirror  will  be  NumberStripes/(NumberMir-\nrors+1),  e.g.  mirrors  1 and stripes 4 will stripe data across\ntwo raid1 mirrors, where each mirror is devices.\n\n--stripesize specifies the size of each stripe in kilobytes.   This  is\nthe  amount  of data that is written to one device before moving\nto the next.\n\nPVs specifies the devices to use.  If not specified,  lvm  will  choose\nthe necessary devices.  Devices are used to create mirrors in the order\nlisted, e.g. for mirrors 1, stripes 2, listing PV1 PV2 PV3 PV4  results\nin mirrors PV1/PV2 and PV3/PV4.\n\nRAID10 is not mirroring on top of stripes, which would be RAID01, which\nis less tolerant of device failures.\n",
            "subsections": []
        },
        "Synchronization": {
            "content": "Synchronization is the process that makes all the devices in a RAID  LV\nconsistent with each other.\n\nIn a RAID1 LV, all mirror images should have the same data.  When a new\nmirror image is added, or a mirror image is missing data,  then  images\nneed to be synchronized.  Data blocks are copied from an existing image\nto a new or outdated image to make them match.\n\nIn a RAID 4/5/6 LV, parity blocks and data blocks should match based on\nthe parity calculation.  When the devices in a RAID LV change, the data\nand parity blocks can become inconsistent and need to be  synchronized.\nCorrect  blocks are read, parity is calculated, and recalculated blocks\nare written.\n\nThe RAID implementation keeps track of which parts of  a  RAID  LV  are\nsynchronized.   When a RAID LV is first created and activated the first\nsynchronization is called initialization.  A pointer stored in the raid\nmetadata  keeps track of the initialization process thus allowing it to\nbe restarted after a deactivation of the RaidLV or a crash.  Any writes\nto  the RaidLV dirties the respective region of the write intent bitmap\nwhich allow for fast recovery of the regions after  a  crash.   Without\nthis, the entire LV would need to be synchronized every time it was ac-\ntivated.\n\nAutomatic synchronization happens when a RAID LV is activated,  but  it\nis  usually  partial  because  the  bitmaps  reduce  the areas that are\nchecked.  A full sync becomes necessary when devices in the RAID LV are\nreplaced.\n\nThe  synchronization  status  of a RAID LV is reported by the following\ncommand, where \"Cpy%Sync\" = \"100%\" means sync is complete:\n\nlvs -a -o name,syncpercent\n\nScrubbing\nScrubbing is a full scan of the RAID LV requested by a user.  Scrubbing\ncan find problems that are missed by partial synchronization.\n\nScrubbing  assumes that RAID metadata and bitmaps may be inaccurate, so\nit verifies all RAID metadata, LV data, and parity  blocks.   Scrubbing\ncan  find  inconsistencies  caused  by  hardware errors or degradation.\nThese kinds of problems may be undetected by automatic  synchronization\nwhich excludes areas outside of the RAID write-intent bitmap.\n\nThe command to scrub a RAID LV can operate in two different modes:\n\nlvchange --syncaction check|repair LV\n\ncheck  Check  mode  is read-only and only detects inconsistent areas in\nthe RAID LV, it does not correct them.\n\nrepair Repair mode checks and writes corrected  blocks  to  synchronize\nany inconsistent areas.\n\nScrubbing  can consume a lot of bandwidth and slow down application I/O\non the RAID LV.  To control the I/O rate used for scrubbing, use:\n\n--maxrecoveryrate Size[k|UNIT]\nSets the maximum recovery rate for a RAID LV.  Size is specified\nas  an  amount  per  second for each device in the array.  If no\nsuffix is given, then KiB/sec/device is used.  Setting  the  re-\ncovery rate to 0 means it will be unbounded.\n\n--minrecoveryrate Size[k|UNIT]\nSets the minimum recovery rate for a RAID LV.  Size is specified\nas an amount per second for each device in  the  array.   If  no\nsuffix  is  given, then KiB/sec/device is used.  Setting the re-\ncovery rate to 0 means it will be unbounded.\n\nTo display the current scrubbing in progress on an  LV,  including  the\nsyncaction mode and percent complete, run:\n\nlvs -a -o name,raidsyncaction,syncpercent\n\nAfter  scrubbing  is  complete,  to  display the number of inconsistent\nblocks found, run:\n\nlvs -o name,raidmismatchcount\n\nAlso, if mismatches were found, the lvs attr  field  will  display  the\nletter \"m\" (mismatch) in the 9th position, e.g.\n\n# lvs -o name,vgname,segtype,attr vg/lv\nLV VG   Type  Attr\nlv vg   raid1 Rwi-a-r-m-\n\nScrubbing Limitations\nThe  check  mode  can only report the number of inconsistent blocks, it\ncannot report which blocks are inconsistent.  This makes it  impossible\nto  know  which  device has errors, or if the errors affect file system\ndata, metadata or nothing at all.\n\nThe repair mode can make the RAID LV data consistent, but it  does  not\nknow which data is correct.  The result may be consistent but incorrect\ndata.  When two different blocks of data must be  made  consistent,  it\nchooses  the  block  from the device that would be used during RAID in-\ntialization.  However,  if  the  PV  holding  corrupt  data  is  known,\nlvchange --rebuild can be used in place of scrubbing to reconstruct the\ndata on the bad device.\n\nFuture developments might include:\n\nAllowing a user to choose the correct version of data during repair.\n\nUsing a majority of devices to determine the correct version of data to\nuse in a 3-way RAID1 or RAID6 LV.\n\nUsing  a  checksumming  device to pin-point when and where an error oc-\ncurs, allowing it to be rewritten.\n",
            "subsections": []
        },
        "SubLVs": {
            "content": "An LV is often a combination of other hidden LVs  called  SubLVs.   The\nSubLVs  either  use  physical  devices,  or are built from other SubLVs\nthemselves.  SubLVs hold LV data blocks, RAID parity blocks,  and  RAID\nmetadata.   SubLVs  are  generally  hidden, so the lvs -a option is re-\nquired to display them:\n\nlvs -a -o name,segtype,devices\n\nSubLV names begin with the visible LV name, and have an automatic  suf-\nfix indicating its role:\n\no  SubLVs  holding  LV data or parity blocks have the suffix rimage#.\nThese SubLVs are sometimes referred to as DataLVs.\n\no  SubLVs holding RAID metadata have the suffix rmeta#.   RAID  meta-\ndata  includes superblock information, RAID type, bitmap, and device\nhealth information.  These SubLVs are sometimes referred to as  Met-\naLVs.\n\nSubLVs  are an internal implementation detail of LVM.  The way they are\nused, constructed and named may change.\n\nThe following examples show the SubLV arrangement for each of the basic\nRAID LV types, using the fewest number of devices allowed for each.\n\nExamples\nraid0\nEach  rimage  SubLV holds a portion of LV data.  No parity is used.  No\nRAID metadata is used.\n\n# lvcreate --type raid0 --stripes 2 --name lvr0 ...\n\n# lvs -a -o name,segtype,devices\nlvr0            raid0  lvr0rimage0(0),lvr0rimage1(0)\n[lvr0rimage0] linear /dev/sda(...)\n[lvr0rimage1] linear /dev/sdb(...)\n\nraid1\nEach rimage SubLV holds a complete copy of LV data.  No parity is used.\nEach rmeta SubLV holds RAID metadata.\n\n# lvcreate --type raid1 --mirrors 1 --name lvr1 ...\n\n# lvs -a -o name,segtype,devices\nlvr1            raid1  lvr1rimage0(0),lvr1rimage1(0)\n[lvr1rimage0] linear /dev/sda(...)\n[lvr1rimage1] linear /dev/sdb(...)\n[lvr1rmeta0]  linear /dev/sda(...)\n[lvr1rmeta1]  linear /dev/sdb(...)\n\nraid4\nAt  least  three  rimage  SubLVs each hold a portion of LV data and one\nrimage SubLV holds parity.  Each rmeta SubLV holds RAID metadata.\n\n# lvcreate --type raid4 --stripes 2 --name lvr4 ...\n\n# lvs -a -o name,segtype,devices\nlvr4            raid4  lvr4rimage0(0),\\\nlvr4rimage1(0),\\\nlvr4rimage2(0)\n[lvr4rimage0] linear /dev/sda(...)\n[lvr4rimage1] linear /dev/sdb(...)\n[lvr4rimage2] linear /dev/sdc(...)\n[lvr4rmeta0]  linear /dev/sda(...)\n[lvr4rmeta1]  linear /dev/sdb(...)\n[lvr4rmeta2]  linear /dev/sdc(...)\n\nraid5\nAt least three rimage SubLVs each typcially hold a portion of  LV  data\nand parity (see section on raid5) Each rmeta SubLV holds RAID metadata.\n\n# lvcreate --type raid5 --stripes 2 --name lvr5 ...\n\n# lvs -a -o name,segtype,devices\nlvr5            raid5  lvr5rimage0(0),\\\nlvr5rimage1(0),\\\nlvr5rimage2(0)\n[lvr5rimage0] linear /dev/sda(...)\n[lvr5rimage1] linear /dev/sdb(...)\n[lvr5rimage2] linear /dev/sdc(...)\n[lvr5rmeta0]  linear /dev/sda(...)\n[lvr5rmeta1]  linear /dev/sdb(...)\n[lvr5rmeta2]  linear /dev/sdc(...)\n\nraid6\nAt  least  five  rimage SubLVs each typically hold a portion of LV data\nand parity.  (see section on raid6) Each rmeta SubLV holds  RAID  meta-\ndata.\n\n# lvcreate --type raid6 --stripes 3 --name lvr6\n\n# lvs -a -o name,segtype,devices\nlvr6            raid6  lvr6rimage0(0),\\\nlvr6rimage1(0),\\\nlvr6rimage2(0),\\\nlvr6rimage3(0),\\\nlvr6rimage4(0),\\\nlvr6rimage5(0)\n[lvr6rimage0] linear /dev/sda(...)\n[lvr6rimage1] linear /dev/sdb(...)\n[lvr6rimage2] linear /dev/sdc(...)\n[lvr6rimage3] linear /dev/sdd(...)\n[lvr6rimage4] linear /dev/sde(...)\n[lvr6rimage5] linear /dev/sdf(...)\n[lvr6rmeta0]  linear /dev/sda(...)\n[lvr6rmeta1]  linear /dev/sdb(...)\n[lvr6rmeta2]  linear /dev/sdc(...)\n[lvr6rmeta3]  linear /dev/sdd(...)\n[lvr6rmeta4]  linear /dev/sde(...)\n[lvr6rmeta5]  linear /dev/sdf(...)\n\nraid10\nAt  least four rimage SubLVs each hold a portion of LV data.  No parity\nis used.  Each rmeta SubLV holds RAID metadata.\n\n# lvcreate --type raid10 --stripes 2 --mirrors 1 --name lvr10\n\n# lvs -a -o name,segtype,devices\nlvr10            raid10 lvr10rimage0(0),\\\nlvr10rimage1(0),\\\nlvr10rimage2(0),\\\nlvr10rimage3(0)\n[lvr10rimage0] linear /dev/sda(...)\n[lvr10rimage1] linear /dev/sdb(...)\n[lvr10rimage2] linear /dev/sdc(...)\n[lvr10rimage3] linear /dev/sdd(...)\n[lvr10rmeta0]  linear /dev/sda(...)\n[lvr10rmeta1]  linear /dev/sdb(...)\n[lvr10rmeta2]  linear /dev/sdc(...)\n[lvr10rmeta3]  linear /dev/sdd(...)\n",
            "subsections": []
        },
        "Device Failure": {
            "content": "Physical devices in a RAID LV can fail or be lost for multiple reasons.\nA device could be disconnected, permanently failed, or temporarily dis-\nconnected.  The purpose of RAID LVs (levels 1 and higher)  is  to  con-\ntinue  operating in a degraded mode, without losing LV data, even after\na device fails.  The number of devices that can fail without  the  loss\nof LV data depends on the RAID level:\n\no  RAID0  (striped)  LVs  cannot  tolerate losing any devices.  LV data\nwill be lost if any devices fail.\n\no  RAID1 LVs can tolerate losing all but one  device  without  LV  data\nloss.\n\no  RAID4  and  RAID5 LVs can tolerate losing one device without LV data\nloss.\n\no  RAID6 LVs can tolerate losing two devices without LV data loss.\n\no  RAID10 is variable, and depends  on  which  devices  are  lost.   It\nstripes  across multiple mirror groups with raid1 layout thus it can\ntolerate losing all but one device in each of these  groups  without\nLV data loss.\n\nIf  a RAID LV is missing devices, or has other device-related problems,\nlvs reports this in the healthstatus (and attr) fields:\n\nlvs -o name,lvhealthstatus\n\npartial\nDevices are missing from the LV.  This is also indicated by the  letter\n\"p\" (partial) in the 9th position of the lvs attr field.\n\nrefresh needed\nA  device was temporarily missing but has returned.  The LV needs to be\nrefreshed to use the device again (which will usually  require  partial\nsynchronization).   This  is  also indicated by the letter \"r\" (refresh\nneeded) in the 9th position of the lvs attr field.  See  Refreshing  an\nLV.   This could also indicate a problem with the device, in which case\nit should be be replaced, see Replacing Devices.\n\nmismatches exist\nSee Scrubbing.\n\nMost commands will also print a warning if a device is missing, e.g.\nWARNING: Device for PV uItL3Z-wBME-DQy0-... not found or rejected ...\n\nThis warning will go away if the device returns or is removed from  the\nVG (see vgreduce --removemissing).\n\nActivating an LV with missing devices\nA RAID LV that is missing devices may be activated or not, depending on\nthe \"activation mode\" used in lvchange:\n\nlvchange -ay --activationmode complete|degraded|partial LV\n\ncomplete\nThe LV is only activated if all devices are present.\n\ndegraded\nThe LV is activated with missing devices if the RAID level can tolerate\nthe number of missing devices without LV data loss.\n\npartial\nThe LV is always activated, even if portions of the LV data are missing\nbecause of the missing device(s).  This should only be used to  perform\nextreme recovery or repair operations.\n\nlvm.conf(5) activation/activationmode\ncontrols the activation mode when not specified by the command.\n\nThe default value is printed by:\nlvmconfig --type default activation/activationmode\n\nReplacing Devices\nDevices  in a RAID LV can be replaced by other devices in the VG.  When\nreplacing devices that are no longer visible on the system, use  lvcon-\nvert  --repair.  When replacing devices that are still visible, use lv-\nconvert --replace.  The repair command will attempt to restore the same\nnumber  of data LVs that were previously in the LV.  The replace option\ncan be repeated to replace multiple PVs.  Replacement  devices  can  be\noptionally listed with either option.\n\nlvconvert --repair LV [NewPVs]\n\nlvconvert --replace OldPV LV [NewPV]\n\nlvconvert --replace OldPV1 --replace OldPV2 LV [NewPVs]\n\nNew devices require synchronization with existing devices, see Synchro-\nnization.\n\nRefreshing an LV\nRefreshing a RAID LV clears any transient device failures  (device  was\ntemporarily  disconnected)  and  returns  the LV to its fully redundant\nmode.  Restoring a device will usually require at  least  partial  syn-\nchronization (see Synchronization).  Failure to clear a transient fail-\nure results in the RAID LV operating in degraded mode until it is reac-\ntivated.  Use the lvchange command to refresh an LV:\n\nlvchange --refresh LV\n\n# lvs -o name,vgname,segtype,attr,size vg\nLV VG   Type  Attr       LSize\nlv vg   raid1 Rwi-a-r-r- 100.00g\n\n# lvchange --refresh vg/lv\n\n# lvs -o name,vgname,segtype,attr,size vg\nLV VG   Type  Attr       LSize\nlv vg   raid1 Rwi-a-r--- 100.00g\n\nAutomatic repair\nIf  a  device  in a RAID LV fails, device-mapper in the kernel notifies\nthe dmeventd(8) monitoring process (see Monitoring).  dmeventd  can  be\nconfigured to automatically respond using:\n\nlvm.conf(5) activation/raidfaultpolicy\n\nPossible settings are:\n\nwarn\nA  warning  is  added  to  the  system log indicating that a device has\nfailed in the RAID LV.  It is left to the user to repair the  LV,  e.g.\nreplace failed devices.\n\nallocate\ndmeventd automatically attempts to repair the LV using spare devices in\nthe VG.  Note that even a transient failure is treated as  a  permanent\nfailure  under  this  setting.  A new device is allocated and full syn-\nchronization is started.\n\nThe specific command run by dmeventd to warn or repair is:\nlvconvert --repair --use-policies LV\n\nCorrupted Data\nData on a device can be corrupted due to hardware  errors  without  the\ndevice  ever  being  disconnected or there being any fault in the soft-\nware.  This should be rare, and can be detected (see Scrubbing).\n\nRebuild specific PVs\nIf specific PVs in a RAID LV are known to have corrupt data,  the  data\non those PVs can be reconstructed with:\n\nlvchange --rebuild PV LV\n\nThe  rebuild  option  can be repeated with different PVs to replace the\ndata on multiple PVs.\n",
            "subsections": []
        },
        "Monitoring": {
            "content": "When a RAID LV is activated the dmeventd(8) process is started to moni-\ntor  the  health  of the LV.  Various events detected in the kernel can\ncause a notification to be sent from device-mapper  to  the  monitoring\nprocess, including device failures and synchronization completion (e.g.\nfor initialization or scrubbing).\n\nThe LVM configuration file contains options that affect how  the  moni-\ntoring process will respond to failure events (e.g. raidfaultpolicy).\nIt is possible to turn on and off monitoring with lvchange, but  it  is\nnot  recommended  to turn this off unless you have a thorough knowledge\nof the consequences.\n",
            "subsections": []
        },
        "Configuration Options": {
            "content": "There are a number of options in the LVM configuration file that affect\nthe behavior of RAID LVs.  The tunable options are listed below.  A de-\ntailed description of each can be found in the LVM  configuration  file\nitself.\nmirrorsegtypedefault\nraid10segtypedefault\nraidregionsize\nraidfaultpolicy\nactivationmode\n",
            "subsections": []
        },
        "Data Integrity": {
            "content": "The device mapper integrity target can be used in combination with RAID\nlevels 1,4,5,6,10 to detect and correct data corruption in RAID images.\nA  dm-integrity layer is placed above each RAID image, and an extra sub\nLV is created to hold integrity metadata (data checksums) for each RAID\nimage.   When  data is read from an image, integrity checksums are used\nto detect corruption. If detected, dm-raid reads the data from  another\n(good)  image to return to the caller.  dm-raid will also automatically\nwrite the good data back to the image with bad data to correct the cor-\nruption.\n\nWhen  creating  a RAID LV with integrity, or adding integrity, space is\nrequired for integrity metadata.  Every 500MB of LV  data  requires  an\nadditional  4MB  to  be allocated for integrity metadata, for each RAID\nimage.\n\nCreate a RAID LV with integrity:\n\nlvcreate --type raidN --raidintegrity y\n\nAdd integrity to an existing RAID LV:\n\nlvconvert --raidintegrity y LV\n\nRemove integrity from a RAID LV:\n\nlvconvert --raidintegrity n LV\n\nIntegrity options\n--raidintegritymode journal|bitmap\n\nUse a journal (default) or bitmap for keeping integrity checksums  con-\nsistent  in  case of a crash. The bitmap areas are recalculated after a\ncrash, so corruption in those areas would not be  detected.  A  journal\ndoes  not  have this problem.  The journal mode doubles writes to stor-\nage, but can improve performance for scattered  writes  packed  into  a\nsingle  journal  write.   bitmap  mode can in theory achieve full write\nthroughput of the device, but would  not  benefit  from  the  potential\nscattered write optimization.\n\n--raidintegrityblocksize 512|1024|2048|4096\n\nThe  block  size to use for dm-integrity on raid images.  The integrity\nblock size should usually match the device logical block size,  or  the\nfile  system  sector/block  sizes.  It may be less than the file system\nsector/block size, but not less than the  device  logical  block  size.\nPossible values: 512, 1024, 2048, 4096.\n\nIntegrity initialization\nWhen  integrity  is  added to an LV, the kernel needs to initialize the\nintegrity metadata (checksums) for all blocks in the LV.  The data cor-\nruption  checking  performed by dm-integrity will only operate on areas\nof the LV that are already initialized.  The progress of integrity ini-\ntialization  is  reported  by the \"syncpercent\" LV reporting field (and\nunder the Cpy%Sync lvs column.)\n\nIntegrity limitations\nTo work around some limitations, it is  possible  to  remove  integrity\nfrom  the  LV,  make  the change, then add integrity again.  (Integrity\nmetadata would need to initialized when added again.)\n\nLVM must be able to allocate the integrity metadata sub LV on a  single\nPV that is already in use by the associated RAID image. This can poten-\ntially cause a problem during lvextend if the original PV  holding  the\nimage  and integrity metadata is full.  To work around this limitation,\nremove integrity, extend the LV, and add integrity again.\n\nAdditional RAID images can be added to raid1 LVs, but not to other raid\nlevels.\n\nA  raid1 LV with integrity cannot be converted to linear (remove integ-\nrity to do this.)\n\nRAID LVs with integrity cannot yet be used as sub  LVs  with  other  LV\ntypes.\n\nThe  following  are not yet permitted on RAID LVs with integrity: lvre-\nduce, pvmove, snapshots, splitmirror, raid  syncaction  commands,  raid\nrebuild.\n\nRAID1 Tuning\nA RAID1 LV can be tuned so that certain devices are avoided for reading\nwhile all devices are still written to.\n\nlvchange --[raid]writemostly PV[:y|n|t] LV\n\nThe specified device will be marked as \"write mostly\", which means that\nreading  from  this  device  will be avoided, and other devices will be\npreferred for reading (unless no other devices  are  available.)   This\nminimizes the I/O to the specified device.\n\nIf  the  PV  name has no suffix, the write mostly attribute is set.  If\nthe PV name has the suffix :n, the write mostly attribute  is  cleared,\nand the suffix :t toggles the current setting.\n\nThe  write  mostly option can be repeated on the command line to change\nmultiple devices at once.\n\nTo report the current write mostly setting, the  lvs  attr  field  will\nshow the letter \"w\" in the 9th position when write mostly is set:\n\nlvs -a -o name,attr\n\nWhen a device is marked write mostly, the maximum number of outstanding\nwrites to that device can be configured.  Once the maximum is  reached,\nfurther writes become synchronous.  When synchronous, a write to the LV\nwill not complete until writes to all the mirror images are complete.\n\nlvchange --[raid]writebehind Number LV\n\nTo report the current write behind setting, run:\n\nlvs -o name,raidwritebehind\n\nWhen write behind is not configured, or set to 0,  all  LV  writes  are\nsynchronous.\n\nRAID Takeover\nRAID  takeover  is converting a RAID LV from one RAID level to another,\ne.g.  raid5 to raid6.  Changing the RAID level is usually done  to  in-\ncrease  or  decrease  resilience to device failures or to restripe LVs.\nThis is done using lvconvert and specifying the new RAID level  as  the\nLV type:\n\nlvconvert --type RaidLevel LV [PVs]\n\nThe most common and recommended RAID takeover conversions are:\n\nlinear to raid1\nLinear  is a single image of LV data, and converting it to raid1\nadds a mirror image which is a direct copy of the original  lin-\near image.\n\nstriped/raid0 to raid4/5/6\nAdding parity devices to a striped volume results in raid4/5/6.\n\nUnnatural  conversions  that are not recommended include converting be-\ntween striped and non-striped types.  This is because file systems  of-\nten  optimize  I/O  patterns based on device striping values.  If those\nvalues change, it can decrease performance.\n\nConverting to a higher RAID level requires  allocating  new  SubLVs  to\nhold  RAID  metadata, and new SubLVs to hold parity blocks for LV data.\nConverting to a lower RAID level removes the SubLVs that are no  longer\nneeded.\n\nConversion often requires full synchronization of the RAID LV (see Syn-\nchronization).  Converting to RAID1 requires copying all LV data blocks\nto  N new images on new devices.  Converting to a parity RAID level re-\nquires reading all LV data blocks, calculating parity, and writing  the\nnew  parity  blocks.  Synchronization can take a long time depending on\nthe throughpout of the devices used and the size of the RaidLV.  It can\ndegrade performance (rate controls also apply to conversion; see --min-\nrecoveryrate and --maxrecoveryrate.)\n\nWarning: though it is possible to create striped LVs  with  up  to  128\nstripes,  a  maximum  of  64  stripes  can be converted to raid0, 63 to\nraid4/5 and 62 to raid6 because of the added parity SubLVs.  A  striped\nLV with a maximum of 32 stripes can be converted to raid10.\n\nThe following takeover conversions are currently possible:\n\no  between striped and raid0.\n\no  between linear and raid1.\n\no  between mirror and raid1.\n\no  between raid1 with two images and raid4/5.\n\no  between striped/raid0 and raid4.\n\no  between striped/raid0 and raid5.\n\no  between striped/raid0 and raid6.\n\no  between raid4 and raid5.\n\no  between raid4/raid5 and raid6.\n\no  between striped/raid0 and raid10.\n\no  between striped and raid4.\n\nIndirect conversions\nConverting  from  one raid level to another may require multiple steps,\nconverting first to intermediate raid levels.\n\nlinear to raid6\n\nTo convert an LV from linear to raid6:\n1. convert to raid1 with two images\n2. convert to raid5 (internally raid5ls) with two images\n3. convert to raid5 with three or more stripes (reshape)\n4. convert to raid6 (internally raid6ls6)\n5. convert to raid6 (internally raid6zr, reshape)\n\nThe commands to perform the steps above are:\n1. lvconvert --type raid1 --mirrors 1 LV\n2. lvconvert --type raid5 LV\n3. lvconvert --stripes 3 LV\n4. lvconvert --type raid6 LV\n5. lvconvert --type raid6 LV\n\nThe final conversion from raid6ls6 to raid6zr is done to  avoid  the\npotential write/recovery performance reduction in raid6ls6 because of\nthe dedicated parity device.  raid6zr rotates data and  parity  blocks\nto avoid this.\n\nlinear to striped\n\nTo convert an LV from linear to striped:\n1. convert to raid1 with two images\n2. convert to raid5n\n3. convert to raid5n with five 128k stripes (reshape)\n4. convert raid5n to striped\n\nThe commands to perform the steps above are:\n1. lvconvert --type raid1 --mirrors 1 LV\n2. lvconvert --type raid5n LV\n3. lvconvert --stripes 5 --stripesize 128k LV\n4. lvconvert --type striped LV\n\nThe raid5n type in step 2 is used because it has dedicated parity Sub-\nLVs at the end, and can be converted to striped directly.   The  stripe\nsize  is  increased  in  step  3  to add extra space for the conversion\nprocess.  This step grows the LV size by a factor of five.  After  con-\nversion, this extra space can be reduced (or used to grow the file sys-\ntem using the LV).\n\nReversing these steps will convert a striped LV to linear.\n\nraid6 to striped\n\nTo convert an LV from raid6nr to striped:\n1. convert to raid6n6\n2. convert to striped\n\nThe commands to perform the steps above are:\n1. lvconvert --type raid6n6 LV\n2. lvconvert --type striped LV\n\nExamples\nConverting an LV from linear to raid1.\n\n# lvs -a -o name,segtype,size vg\nLV   Type   LSize\nlv   linear 300.00g\n\n# lvconvert --type raid1 --mirrors 1 vg/lv\n\n# lvs -a -o name,segtype,size vg\nLV            Type   LSize\nlv            raid1  300.00g\n[lvrimage0] linear 300.00g\n[lvrimage1] linear 300.00g\n[lvrmeta0]  linear   3.00m\n[lvrmeta1]  linear   3.00m\n\nConverting an LV from mirror to raid1.\n\n# lvs -a -o name,segtype,size vg\nLV            Type   LSize\nlv            mirror 100.00g\n[lvmimage0] linear 100.00g\n[lvmimage1] linear 100.00g\n[lvmlog]     linear   3.00m\n\n# lvconvert --type raid1 vg/lv\n\n# lvs -a -o name,segtype,size vg\nLV            Type   LSize\nlv            raid1  100.00g\n[lvrimage0] linear 100.00g\n[lvrimage1] linear 100.00g\n[lvrmeta0]  linear   3.00m\n[lvrmeta1]  linear   3.00m\n\nConverting an LV from linear to raid1 (with 3 images).\n\n# lvconvert --type raid1 --mirrors 2 vg/lv\n\nConverting an LV from striped (with 4 stripes) to raid6n6.\n\n# lvcreate --stripes 4 -L64M -n lv vg\n\n# lvconvert --type raid6 vg/lv\n\n# lvs -a -o lvname,segtype,syncpercent,datacopies\nLV            Type      Cpy%Sync #Cpy\nlv            raid6n6 100.00      3\n[lvrimage0] linear\n[lvrimage1] linear\n[lvrimage2] linear\n[lvrimage3] linear\n[lvrimage4] linear\n[lvrimage5] linear\n[lvrmeta0]  linear\n[lvrmeta1]  linear\n[lvrmeta2]  linear\n[lvrmeta3]  linear\n[lvrmeta4]  linear\n[lvrmeta5]  linear\n\nThis convert begins by allocating MetaLVs (rmeta#) for each of the ex-\nisting  stripe  devices.   It  then  creates 2 additional MetaLV/DataLV\npairs (rmeta#/rimage#) for dedicated raid6 parity.\n\nIf rotating data/parity is required, such as with raid6nr, it must  be\ndone by reshaping (see below).\n\nRAID Reshaping\nRAID  reshaping  is  changing attributes of a RAID LV while keeping the\nsame RAID level.  This includes changing RAID layout, stripe  size,  or\nnumber of stripes.\n\nWhen changing the RAID layout or stripe size, no new SubLVs (MetaLVs or\nDataLVs) need to be allocated, but DataLVs  are  extended  by  a  small\namount (typically 1 extent).  The extra space allows blocks in a stripe\nto be updated safely, and not be corrupted in case of a  crash.   If  a\ncrash occurs, reshaping can just be restarted.\n\n(If  blocks in a stripe were updated in place, a crash could leave them\npartially updated and corrupted.  Instead, an existing stripe  is  qui-\nesced,  read,  changed  in  layout,  and the new stripe written to free\nspace.  Once that is done, the new stripe is unquiesced and used.)\n\nExamples\n(Command output shown in examples may change.)\n\nConverting raid6n6 to raid6nr with rotating data/parity.\n\nThis  conversion  naturally  follows   a   previous   conversion   from\nstriped/raid0  to raid6n6 (shown above).  It completes the transition\nto a more traditional RAID6.\n\n# lvs -o lvname,segtype,syncpercent,datacopies\nLV            Type      Cpy%Sync #Cpy\nlv            raid6n6 100.00      3\n[lvrimage0] linear\n[lvrimage1] linear\n[lvrimage2] linear\n[lvrimage3] linear\n[lvrimage4] linear\n[lvrimage5] linear\n[lvrmeta0]  linear\n[lvrmeta1]  linear\n[lvrmeta2]  linear\n[lvrmeta3]  linear\n[lvrmeta4]  linear\n[lvrmeta5]  linear\n\n# lvconvert --type raid6nr vg/lv\n\n# lvs -a -o lvname,segtype,syncpercent,datacopies\nLV            Type     Cpy%Sync #Cpy\nlv            raid6nr 100.00      3\n[lvrimage0] linear\n[lvrimage0] linear\n[lvrimage1] linear\n[lvrimage1] linear\n[lvrimage2] linear\n[lvrimage2] linear\n[lvrimage3] linear\n[lvrimage3] linear\n[lvrimage4] linear\n[lvrimage5] linear\n[lvrmeta0]  linear\n[lvrmeta1]  linear\n[lvrmeta2]  linear\n[lvrmeta3]  linear\n[lvrmeta4]  linear\n[lvrmeta5]  linear\n\nThe DataLVs are larger (additional  segment  in  each)  which  provides\nspace for out-of-place reshaping.  The result is:\n\n# lvs -a -o lvname,segtype,segperanges,dataoffset\nLV            Type     PE Ranges          DOff\nlv            raid6nr lvrimage0:0-32 \\\nlvrimage1:0-32 \\\nlvrimage2:0-32 \\\nlvrimage3:0-32\n[lvrimage0] linear   /dev/sda:0-31      2048\n[lvrimage0] linear   /dev/sda:33-33\n[lvrimage1] linear   /dev/sdaa:0-31     2048\n[lvrimage1] linear   /dev/sdaa:33-33\n[lvrimage2] linear   /dev/sdab:1-33     2048\n[lvrimage3] linear   /dev/sdac:1-33     2048\n[lvrmeta0]  linear   /dev/sda:32-32\n[lvrmeta1]  linear   /dev/sdaa:32-32\n[lvrmeta2]  linear   /dev/sdab:0-0\n[lvrmeta3]  linear   /dev/sdac:0-0\n\nAll  segments  with  PE ranges '33-33' provide the out-of-place reshape\nspace.  The dataoffset column shows that the data was moved  from  ini-\ntial offset 0 to 2048 sectors on each component DataLV.\n\nFor  performance reasons the raid6nr RaidLV can be restriped.  Convert\nit from 3-way striped to 5-way-striped.\n\n# lvconvert --stripes 5 vg/lv\nUsing default stripesize 64.00 KiB.\nWARNING: Adding stripes to active logical volume vg/lv will \\\ngrow it from 99 to 165 extents!\nRun \"lvresize -l99 vg/lv\" to shrink it or use the additional \\\ncapacity.\nLogical volume vg/lv successfully converted.\n\n# lvs vg/lv\nLV   VG     Attr       LSize   Cpy%Sync\nlv   vg     rwi-a-r-s- 652.00m 52.94\n\n# lvs -a -o lvname,attr,segtype,segperanges,dataoffset vg\nLV            Attr       Type     PE Ranges          DOff\nlv            rwi-a-r--- raid6nr lvrimage0:0-33 \\\nlvrimage1:0-33 \\\nlvrimage2:0-33 ... \\\nlvrimage5:0-33 \\\nlvrimage6:0-33   0\n[lvrimage0] iwi-aor--- linear   /dev/sda:0-32      0\n[lvrimage0] iwi-aor--- linear   /dev/sda:34-34\n[lvrimage1] iwi-aor--- linear   /dev/sdaa:0-32     0\n[lvrimage1] iwi-aor--- linear   /dev/sdaa:34-34\n[lvrimage2] iwi-aor--- linear   /dev/sdab:0-32     0\n[lvrimage2] iwi-aor--- linear   /dev/sdab:34-34\n[lvrimage3] iwi-aor--- linear   /dev/sdac:1-34     0\n[lvrimage4] iwi-aor--- linear   /dev/sdad:1-34     0\n[lvrimage5] iwi-aor--- linear   /dev/sdae:1-34     0\n[lvrimage6] iwi-aor--- linear   /dev/sdaf:1-34     0\n[lvrmeta0]  ewi-aor--- linear   /dev/sda:33-33\n[lvrmeta1]  ewi-aor--- linear   /dev/sdaa:33-33\n[lvrmeta2]  ewi-aor--- linear   /dev/sdab:33-33\n[lvrmeta3]  ewi-aor--- linear   /dev/sdac:0-0\n[lvrmeta4]  ewi-aor--- linear   /dev/sdad:0-0\n[lvrmeta5]  ewi-aor--- linear   /dev/sdae:0-0\n[lvrmeta6]  ewi-aor--- linear   /dev/sdaf:0-0\n\nStripes also can be removed  from  raid5  and  6.   Convert  the  5-way\nstriped  raid6nr  LV  to  4-way-striped.  The force option needs to be\nused, because removing stripes (i.e. image SubLVs) from a  RaidLV  will\nshrink its size.\n\n# lvconvert --stripes 4 vg/lv\nUsing default stripesize 64.00 KiB.\nWARNING: Removing stripes from active logical volume vg/lv will \\\nshrink it from 660.00 MiB to 528.00 MiB!\nTHIS MAY DESTROY (PARTS OF) YOUR DATA!\nIf that leaves the logical volume larger than 206 extents due \\\nto stripe rounding,\nyou may want to grow the content afterwards (filesystem etc.)\nWARNING: to remove freed stripes after the conversion has finished,\\\nyou have to run \"lvconvert --stripes 4 vg/lv\"\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o lvname,attr,segtype,segperanges,dataoffset vg\nLV            Attr       Type     PE Ranges          DOff\nlv            rwi-a-r-s- raid6nr lvrimage0:0-33 \\\nlvrimage1:0-33 \\\nlvrimage2:0-33 ... \\\nlvrimage5:0-33 \\\nlvrimage6:0-33   0\n[lvrimage0] Iwi-aor--- linear   /dev/sda:0-32      0\n[lvrimage0] Iwi-aor--- linear   /dev/sda:34-34\n[lvrimage1] Iwi-aor--- linear   /dev/sdaa:0-32     0\n[lvrimage1] Iwi-aor--- linear   /dev/sdaa:34-34\n[lvrimage2] Iwi-aor--- linear   /dev/sdab:0-32     0\n[lvrimage2] Iwi-aor--- linear   /dev/sdab:34-34\n[lvrimage3] Iwi-aor--- linear   /dev/sdac:1-34     0\n[lvrimage4] Iwi-aor--- linear   /dev/sdad:1-34     0\n[lvrimage5] Iwi-aor--- linear   /dev/sdae:1-34     0\n[lvrimage6] Iwi-aor-R- linear   /dev/sdaf:1-34     0\n[lvrmeta0]  ewi-aor--- linear   /dev/sda:33-33\n[lvrmeta1]  ewi-aor--- linear   /dev/sdaa:33-33\n[lvrmeta2]  ewi-aor--- linear   /dev/sdab:33-33\n[lvrmeta3]  ewi-aor--- linear   /dev/sdac:0-0\n[lvrmeta4]  ewi-aor--- linear   /dev/sdad:0-0\n[lvrmeta5]  ewi-aor--- linear   /dev/sdae:0-0\n[lvrmeta6]  ewi-aor-R- linear   /dev/sdaf:0-0\n\nThe  's'  in  column 9 of the attribute field shows the RaidLV is still\nreshaping.  The 'R' in the same column of the attribute field shows the\nfreed  image  Sub  LVs which will need removing once the reshaping fin-\nished.\n\n# lvs -o lvname,attr,segtype,segperanges,dataoffset vg\nLV   Attr       Type     PE Ranges          DOff\nlv   rwi-a-r-R- raid6nr lvrimage0:0-33 \\\nlvrimage1:0-33 \\\nlvrimage2:0-33 ... \\\nlvrimage5:0-33 \\\nlvrimage6:0-33   8192\n\nNow that the reshape is finished the 'R' atribute on the  RaidLV  shows\nimages can be removed.\n\n# lvs -o lvname,attr,segtype,segperanges,dataoffset vg\nLV   Attr       Type     PE Ranges          DOff\nlv   rwi-a-r-R- raid6nr lvrimage0:0-33 \\\nlvrimage1:0-33 \\\nlvrimage2:0-33 ... \\\nlvrimage5:0-33 \\\nlvrimage6:0-33   8192\n\nThis  is  achieved  by  repeating  the  command (\"lvconvert --stripes 4\nvg/lv\" would be sufficient).\n\n# lvconvert --stripes 4 vg/lv\nUsing default stripesize 64.00 KiB.\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o lvname,attr,segtype,segperanges,dataoffset vg\nLV            Attr       Type     PE Ranges          DOff\nlv            rwi-a-r--- raid6nr lvrimage0:0-33 \\\nlvrimage1:0-33 \\\nlvrimage2:0-33 ... \\\nlvrimage5:0-33   8192\n[lvrimage0] iwi-aor--- linear   /dev/sda:0-32      8192\n[lvrimage0] iwi-aor--- linear   /dev/sda:34-34\n[lvrimage1] iwi-aor--- linear   /dev/sdaa:0-32     8192\n[lvrimage1] iwi-aor--- linear   /dev/sdaa:34-34\n[lvrimage2] iwi-aor--- linear   /dev/sdab:0-32     8192\n[lvrimage2] iwi-aor--- linear   /dev/sdab:34-34\n[lvrimage3] iwi-aor--- linear   /dev/sdac:1-34     8192\n[lvrimage4] iwi-aor--- linear   /dev/sdad:1-34     8192\n[lvrimage5] iwi-aor--- linear   /dev/sdae:1-34     8192\n[lvrmeta0]  ewi-aor--- linear   /dev/sda:33-33\n[lvrmeta1]  ewi-aor--- linear   /dev/sdaa:33-33\n[lvrmeta2]  ewi-aor--- linear   /dev/sdab:33-33\n[lvrmeta3]  ewi-aor--- linear   /dev/sdac:0-0\n[lvrmeta4]  ewi-aor--- linear   /dev/sdad:0-0\n[lvrmeta5]  ewi-aor--- linear   /dev/sdae:0-0\n\n# lvs -a -o lvname,attr,segtype,reshapelen vg\nLV            Attr       Type     RSize\nlv            rwi-a-r--- raid6nr 24.00m\n[lvrimage0] iwi-aor--- linear    4.00m\n[lvrimage0] iwi-aor--- linear\n[lvrimage1] iwi-aor--- linear    4.00m\n[lvrimage1] iwi-aor--- linear\n[lvrimage2] iwi-aor--- linear    4.00m\n[lvrimage2] iwi-aor--- linear\n[lvrimage3] iwi-aor--- linear    4.00m\n[lvrimage4] iwi-aor--- linear    4.00m\n[lvrimage5] iwi-aor--- linear    4.00m\n[lvrmeta0]  ewi-aor--- linear\n[lvrmeta1]  ewi-aor--- linear\n[lvrmeta2]  ewi-aor--- linear\n[lvrmeta3]  ewi-aor--- linear\n[lvrmeta4]  ewi-aor--- linear\n[lvrmeta5]  ewi-aor--- linear\n\nFuture developments might include automatic removal of  the  freed  im-\nages.\n\nIf  the reshape space shall be removed any lvconvert command not chang-\ning the layout can be used:\n\n# lvconvert --stripes 4 vg/lv\nUsing default stripesize 64.00 KiB.\nNo change in RAID LV vg/lv layout, freeing reshape space.\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o lvname,attr,segtype,reshapelen vg\nLV            Attr       Type     RSize\nlv            rwi-a-r--- raid6nr    0\n[lvrimage0] iwi-aor--- linear      0\n[lvrimage0] iwi-aor--- linear\n[lvrimage1] iwi-aor--- linear      0\n[lvrimage1] iwi-aor--- linear\n[lvrimage2] iwi-aor--- linear      0\n[lvrimage2] iwi-aor--- linear\n[lvrimage3] iwi-aor--- linear      0\n[lvrimage4] iwi-aor--- linear      0\n[lvrimage5] iwi-aor--- linear      0\n[lvrmeta0]  ewi-aor--- linear\n[lvrmeta1]  ewi-aor--- linear\n[lvrmeta2]  ewi-aor--- linear\n[lvrmeta3]  ewi-aor--- linear\n[lvrmeta4]  ewi-aor--- linear\n[lvrmeta5]  ewi-aor--- linear\n\nIn case the RaidLV should be converted to striped:\n\n# lvconvert --type striped vg/lv\nUnable to convert LV vg/lv from raid6nr to striped.\nConverting vg/lv from raid6nr is directly possible to the \\\nfollowing layouts:\nraid6nc\nraid6zr\nraid6la6\nraid6ls6\nraid6ra6\nraid6rs6\nraid6n6\n\nA direct conversion isn't possible thus the command informed about  the\npossible  ones.  raid6n6 is suitable to convert to striped so convert\nto it first (this is a reshape changing the raid6 layout from  raid6nr\nto raid6n6).\n\n# lvconvert --type raid6n6\nUsing default stripesize 64.00 KiB.\nConverting raid6nr LV vg/lv to raid6n6.\nAre you sure you want to convert raid6nr LV vg/lv? [y/n]: y\nLogical volume vg/lv successfully converted.\n\nWait for the reshape to finish.\n\n# lvconvert --type striped vg/lv\nLogical volume vg/lv successfully converted.\n\n# lvs -o lvname,attr,segtype,segperanges,dataoffset vg\nLV   Attr       Type    PE Ranges  DOff\nlv   -wi-a----- striped /dev/sda:2-32 \\\n/dev/sdaa:2-32 \\\n/dev/sdab:2-32 \\\n/dev/sdac:3-33\nlv   -wi-a----- striped /dev/sda:34-35 \\\n/dev/sdaa:34-35 \\\n/dev/sdab:34-35 \\\n/dev/sdac:34-35\n\nFrom striped we can convert to raid10\n\n# lvconvert --type raid10 vg/lv\nUsing default stripesize 64.00 KiB.\nLogical volume vg/lv successfully converted.\n\n# lvs -o lvname,attr,segtype,segperanges,dataoffset vg\nLV   Attr       Type   PE Ranges          DOff\nlv   rwi-a-r--- raid10 lvrimage0:0-32 \\\nlvrimage4:0-32 \\\nlvrimage1:0-32 ... \\\nlvrimage3:0-32 \\\nlvrimage7:0-32   0\n\n# lvs -a -o lvname,attr,segtype,segperanges,dataoffset vg\nWARNING: Cannot find matching striped segment for vg/lvrimage3.\nLV            Attr       Type   PE Ranges          DOff\nlv            rwi-a-r--- raid10 lvrimage0:0-32 \\\nlvrimage4:0-32 \\\nlvrimage1:0-32 ... \\\nlvrimage3:0-32 \\\nlvrimage7:0-32   0\n[lvrimage0] iwi-aor--- linear /dev/sda:2-32      0\n[lvrimage0] iwi-aor--- linear /dev/sda:34-35\n[lvrimage1] iwi-aor--- linear /dev/sdaa:2-32     0\n[lvrimage1] iwi-aor--- linear /dev/sdaa:34-35\n[lvrimage2] iwi-aor--- linear /dev/sdab:2-32     0\n[lvrimage2] iwi-aor--- linear /dev/sdab:34-35\n[lvrimage3] iwi-XXr--- linear /dev/sdac:3-35     0\n[lvrimage4] iwi-aor--- linear /dev/sdad:1-33     0\n[lvrimage5] iwi-aor--- linear /dev/sdae:1-33     0\n[lvrimage6] iwi-aor--- linear /dev/sdaf:1-33     0\n[lvrimage7] iwi-aor--- linear /dev/sdag:1-33     0\n[lvrmeta0]  ewi-aor--- linear /dev/sda:0-0\n[lvrmeta1]  ewi-aor--- linear /dev/sdaa:0-0\n[lvrmeta2]  ewi-aor--- linear /dev/sdab:0-0\n[lvrmeta3]  ewi-aor--- linear /dev/sdac:0-0\n[lvrmeta4]  ewi-aor--- linear /dev/sdad:0-0\n[lvrmeta5]  ewi-aor--- linear /dev/sdae:0-0\n[lvrmeta6]  ewi-aor--- linear /dev/sdaf:0-0\n[lvrmeta7]  ewi-aor--- linear /dev/sdag:0-0\n\nraid10 allows to add stripes but can't remove them.\n\nA more elaborate example to convert from linear to striped with interim\nconversions to raid1 then raid5 followed by restripe (4 steps).\n\nWe start with the linear LV.\n\n# lvs -a -o name,size,segtype,syncpercent,datastripes,\\\nstripesize,reshapelenle,devices vg\nLV   LSize   Type   Cpy%Sync #DStr Stripe RSize Devices\nlv   128.00m linear              1     0        /dev/sda(0)\n\nThen convert it to a 2-way raid1.\n\n# lvconvert --mirrors 1 vg/lv\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o name,size,segtype,datastripes,\\\nstripesize,reshapelenle,devices vg\nLV            LSize   Type   #DStr Stripe RSize Devices\nlv            128.00m raid1      2     0        lvrimage0(0),\\\nlvrimage1(0)\n[lvrimage0] 128.00m linear     1     0        /dev/sda(0)\n[lvrimage1] 128.00m linear     1     0        /dev/sdhx(1)\n[lvrmeta0]    4.00m linear     1     0        /dev/sda(32)\n[lvrmeta1]    4.00m linear     1     0        /dev/sdhx(0)\n\nOnce the raid1 LV is fully synchronized we convert it to raid5n  (only\n2-way raid1 LVs can be converted to raid5).  We select raid5n here be-\ncause it has dedicated parity SubLVs at the end and can be converted to\nstriped directly without any additional conversion.\n\n# lvconvert --type raid5n vg/lv\nUsing default stripesize 64.00 KiB.\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o name,size,segtype,syncpercent,datastripes,\\\nstripesize,reshapelenle,devices vg\nLV            LSize   Type    #DStr Stripe RSize Devices\nlv            128.00m raid5n     1 64.00k     0 lvrimage0(0),\\\nlvrimage1(0)\n[lvrimage0] 128.00m linear      1     0      0 /dev/sda(0)\n[lvrimage1] 128.00m linear      1     0      0 /dev/sdhx(1)\n[lvrmeta0]    4.00m linear      1     0        /dev/sda(32)\n[lvrmeta1]    4.00m linear      1     0        /dev/sdhx(0)\n\nNow  we'll  change  the  number of data stripes from 1 to 5 and request\n128K stripe size in one command.  This will grow the size of the LV  by\na factor of 5 (we add 4 data stripes to the one given).  That additonal\nspace can be used by e.g. growing any contained filesystem  or  the  LV\ncan be reduced in size after the reshaping conversion has finished.\n\n# lvconvert --stripesize 128k --stripes 5 vg/lv\nConverting stripesize 64.00 KiB of raid5n LV vg/lv to 128.00 KiB.\nWARNING: Adding stripes to active logical volume vg/lv will grow \\\nit from 32 to 160 extents!\nRun \"lvresize -l32 vg/lv\" to shrink it or use the additional capacity.\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o name,size,segtype,datastripes,\\\nstripesize,reshapelenle,devices\nLV            LSize   Type    #DStr Stripe  RSize Devices\nlv            640.00m raid5n     5 128.00k     6 lvrimage0(0),\\\nlvrimage1(0),\\\nlvrimage2(0),\\\nlvrimage3(0),\\\nlvrimage4(0),\\\nlvrimage5(0)\n[lvrimage0] 132.00m linear      1      0      1 /dev/sda(33)\n[lvrimage0] 132.00m linear      1      0        /dev/sda(0)\n[lvrimage1] 132.00m linear      1      0      1 /dev/sdhx(33)\n[lvrimage1] 132.00m linear      1      0        /dev/sdhx(1)\n[lvrimage2] 132.00m linear      1      0      1 /dev/sdhw(33)\n[lvrimage2] 132.00m linear      1      0        /dev/sdhw(1)\n[lvrimage3] 132.00m linear      1      0      1 /dev/sdhv(33)\n[lvrimage3] 132.00m linear      1      0        /dev/sdhv(1)\n[lvrimage4] 132.00m linear      1      0      1 /dev/sdhu(33)\n[lvrimage4] 132.00m linear      1      0        /dev/sdhu(1)\n[lvrimage5] 132.00m linear      1      0      1 /dev/sdht(33)\n[lvrimage5] 132.00m linear      1      0        /dev/sdht(1)\n[lvrmeta0]    4.00m linear      1      0        /dev/sda(32)\n[lvrmeta1]    4.00m linear      1      0        /dev/sdhx(0)\n[lvrmeta2]    4.00m linear      1      0        /dev/sdhw(0)\n[lvrmeta3]    4.00m linear      1      0        /dev/sdhv(0)\n[lvrmeta4]    4.00m linear      1      0        /dev/sdhu(0)\n[lvrmeta5]    4.00m linear      1      0        /dev/sdht(0)\n\nOnce the conversion has finished we can can convert to striped.\n\n# lvconvert --type striped vg/lv\nLogical volume vg/lv successfully converted.\n\n# lvs -a -o name,size,segtype,datastripes,\\\nstripesize,reshapelenle,devices vg\nLV   LSize   Type    #DStr Stripe  RSize Devices\nlv   640.00m striped     5 128.00k       /dev/sda(33),\\\n/dev/sdhx(33),\\\n/dev/sdhw(33),\\\n/dev/sdhv(33),\\\n/dev/sdhu(33)\nlv   640.00m striped     5 128.00k       /dev/sda(0),\\\n/dev/sdhx(1),\\\n/dev/sdhw(1),\\\n/dev/sdhv(1),\\\n/dev/sdhu(1)\n\nReversing these steps will convert a given striped LV to linear.\n\nMind the facts that stripes are removed thus the capacity of the RaidLV\nwill shrink and that changing the RaidLV layout will influence its per-\nformance.\n\n\"lvconvert  --stripes  1  vg/lv\" for converting to 1 stripe will inform\nupfront about the reduced size to allow for  resizing  the  content  or\ngrowing the RaidLV before actually converting to 1 stripe.  The --force\noption is needed to allow stripe removing conversions to  prevent  data\nloss.\n\nOf course any interim step can be the intended last one (e.g. striped->\nraid1).\n\nRAID5 Variants\nraid5ls\no RAID5 left symmetric\no Rotating parity N with data restart\n\nraid5la\no RAID5 left symmetric\no Rotating parity N with data continuation\n\nraid5rs\no RAID5 right symmetric\no Rotating parity 0 with data restart\n\nraid5ra\no RAID5 right asymmetric\no Rotating parity 0 with data continuation\n\nraid5n\no RAID5 parity n\no Dedicated parity device n used for striped/raid0 conversions\no Used for RAID Takeover\n\nRAID6 Variants\nraid6\no RAID6 zero restart (aka left symmetric)\no Rotating parity 0 with data restart\no Same as raid6zr\n\nraid6zr\no RAID6 zero restart (aka left symmetric)\no Rotating parity 0 with data restart\n\nraid6nr\no RAID6 N restart (aka right symmetric)\no Rotating parity N with data restart\n\nraid6nc\no RAID6 N continue\no Rotating parity N with data continuation\n\nraid6n6\no RAID6 last parity devices\no Fixed dedicated last devices (P-Syndrome N-1 and Q-Syndrome N)\nwith striped data used for striped/raid0 conversions\no Used for RAID Takeover\n\nraid6{ls,rs,la,ra}6\no RAID6 last parity device\no Dedicated last parity device used for conversions from/to\nraid5{ls,rs,la,ra}\n\nraid6ls6\no RAID6 N continue\no Same as raid5ls for N-1 devices with fixed Q-Syndrome N\no Used for RAID Takeover\n\nraid6la6\no RAID6 N continue\no Same as raid5la for N-1 devices with fixed Q-Syndrome N\no Used forRAID Takeover\n\nraid6rs6\no RAID6 N continue\no Same as raid5rs for N-1 devices with fixed Q-Syndrome N\no Used for RAID Takeover\n\nraid6ra6\no RAID6 N continue\no ame as raid5ra for N-1 devices with fixed Q-Syndrome N\no Used for RAID Takeover\n",
            "subsections": []
        },
        "History": {
            "content": "The 2.6.38-rc1 version of the Linux kernel introduced  a  device-mapper\ntarget  to  interface  with the software RAID (MD) personalities.  This\nprovided device-mapper with RAID 4/5/6 capabilities and a larger devel-\nopment  community.   Later, support for RAID1, RAID10, and RAID1E (RAID\n10 variants) were added.  Support for these new kernel RAID targets was\nadded  to  LVM version 2.02.87.  The capabilities of the LVM raid1 type\nhave surpassed the old mirror type.  raid1 is now  recommended  instead\nof  mirror.   raid1  became  the  default  for mirroring in LVM version\n2.02.100.\n\nRed Hat, Inc           LVM TOOLS 2.03.11(2) (2021-01-08)            LVMRAID(7)",
            "subsections": []
        }
    },
    "summary": "lvmraid -- LVM RAID",
    "flags": [],
    "examples": [],
    "see_also": []
}