LVM/ko

LVM(Logical Volume Manager)은 관리자가 파일 시스템과 사용 중인 물리 저장소 사이의 추상 레이어를 제공하여 메타 장치를 만들 수 있게 합니다. (파일 시스템이 있는)메타 장치는 논리 볼륨이며, 저장소 풀에서 사용하는 저장소를 볼륨 그룹 이라고 합니다. 볼륨 그룹은 데이터를 저장하는 하나 이상의 실제 장치로 구성되어있습니다.

물리 볼륨은 파티션으로 구성되어 있고, 전체 SATA 하드 디스크 드라이브는 JBOD(Just a Bunch Of Disks), RAID 체계, iSCSI, 광 채널, eSATA 등으로 묶습니다.

설치
LVM은 설정을 관리하기 위해 커널 수준의 드라이버와 사용자 영역 프로그램으로 다룹니다.

커널
다음 커널 옵션을 활성화하십시오:

프로그램
를 설치하십시오:

설정
LVM 설정은 다음 몇가지 단계에서 처리할 수 있습니다:
 * 1) 관리 유틸리티를 통한 LV, PV, VG 관리
 * 2) 설정 파일을 통한 LVM 하위시스템 세부 설정
 * 3) 분산 차원 서비스 관리
 * 4) 초기화 RAM 파일 시스템 설정

논리, 물리 볼륨 및 볼륨 그룹의 관리는 사용법 장에서 다룹니다.

LVM 설정 파일
LVM은 에 더 많이 설정할 수 있는 파일이 있습니다. 대부분의 사용자는 LVM 사용을 시작하는데 이 파일의 설정을 수정할 필요가 없습니다.�

서비스 관리
젠투에서는 볼륨 그룹과 논리 볼륨을 자동으로 감지하고 활성화 하는 LVM 서비스를 제공합니다.

서비스는 init 시스템에서 관리할 수 있습니다.

openrc
LVM을 별도로 시작하려면:

부팅시 LVM을 시작하려면:

systemd
lvm을 별도로 시작하려면:

부팅할 때 LVM을 시작하려면:

initramfs에서 LVM 사용하기
대부분의 부트 로더는 LVM에서 직접 부팅할 수 있습니다. 기존의 GRUB은 물론이고 LILO에서도 안됩니다. Grub2는 LVM 선형 논리 볼륨, 미러링한 논리 볼륨, 몇가지 RAID 논리 볼륨으로 부팅할 수 있습니다. 씬 논리 볼륨을 지원하는 부트로더는 없습니다.

이런 이유로, /boot 파티션은 비 LVM 파티션으로 사용하고 initramfs에서 LVM 루트를 마운트하는 방식을 권장합니다. initramfs 같은요소는 genkernel, genkernel-next, dracut에서 자동으로 만들 수 있습니다:


 * genkernel은 씬 볼륨(빌드 호스트에서 나온 thin-provisioning-tools 바이너리 사본이나 빌드도 마찬가지로)과 RAID10(RAID10은 LVM10 2.02.98을 필요로 하겠지만, genkernel은 2.02.89를 빌드하는데, 정적 바이너리가 있다면 복사할 수 있습니다)을 제외한 모든 형식의 파티션에서 부팅할 수 있습니다.
 * genkernel-next에서는 모든 형식의 볼륨에서 부팅할 수 있습니다만, 충분히 최신의 app-misc/pax-utils가 필요하며, 그렇지 않으면 씬 바이너리가 깨집니다( 참고)
 * dracut은 모든 형식의 볼륨에서 부팅하지만, 씬 루트가 있는 상태에서 호스트가 동작하는 경우 initramfs에서 씬을 지원하는 호스트에서만 부팅합니다.

Genkernel/Genkernel-next
또는 둘 중 하나를 이머지하십시오. 패키지를 이머지할 때는 static USE 플래그를 활성화하여 genkernel이 시스템 바이너리를 사용할 수 있게 하십시오(그렇지 않으면 자체 사본을 만듭니다). 다음 예제에서는 initramfs(전체 커널 아님)만 빌드하며 lvm 지원을 활성화합니다.

genkernel 맨페이지에서는 시스템 요구사항에 따라 다른 옵션을 설명합니다.

initrd는 lvm 시작 방법을 알리는 매개 변수가 필요하며, 다른 커널 매개 변수를 넣는 동일한 방식으로 처리합니다. 예를 들면:

Dracut
꾸러미는 레드햇 프로젝트에서 이식했으며, initramfs를 만드는 유사한 도구를 제공합니다. 시험 목적으로 ~arch 상태에 있기 때문에 이머지를 하려면 사용자 여러분은( 에서)이 글대로 하셔야합니다. 이 과정을 수행하기 전에 에 를 추가해야 합니다. 다른 모듈을 사용한다면, Dracut을 참고하십시오. 보통 다음 명령을 통해, 활용 가능한 기본 initramfs를 만듭니다.

initrd는 lvm 시작 방법을 알리는 매개 변수가 필요하며, 다른 커널 매개 변수를 넣는 동일한 방식으로 처리합니다. 예를 들면:

dracut에서 활용하는 lvm 옵션 실제 목록을 보려면 Dracut 설명서의 LVM 장을 참고하십시오.

사용법
LVM은 다음 세가지 레벨의 저장소로 구성되어 있습니다:
 * 하드 디스크 드라이브, 파티션, RAID 시스템 또는 저장소의 다른 개념을 물리 볼륨(PV)으로 초기화합니다
 * 물리 볼륨(PV)은 볼륨 그룹(VG)으로 묶습니다
 * 논리 볼륨(LV)은 볼륨 그룹(VG)에서 관리합니다

PV(물리 볼륨)
물리 볼륨은 LVM을 구축할 실제 하드웨어 또는 저장장치 입니다.

공간 분할
LVM의 분할 공간 형식은 8e(Linux LVM)입니다.

가령,  로 의 파티션을 설정한다면:

에서, 분할 공간을 만들려면 n키를 사용하고, t키를 사용하여 분할 공간 형식을 8e로 바꾸십시오.

PV 만들기
물리 볼륨은 명령으로 만들고 초기화 할 수 있습니다.

가령, 다음 명령을 사용하면 와 의 첫번째 처음 파티션의 물리 볼륨을 만듭니다:

PV 목록 표시
명령으로 시스템에 활성화 된 모든 물리 볼륨의 개요를 볼 수 있습니다.

더 많은 물리 볼륨을 표시해야 한다면,  명령으로 비활성화된 물리 볼륨을 감지하고, 활성화 할 수 있습니다.

PV 제거
LVM은 (다른 방식을 언급하지 않는 한)존재하는 모든 물리 볼륨에 데이터를 넣는데, 연속적인 접근 방식으로 넣습니다. (볼륨 그룹 내)논리 볼륨 논리 볼륨이 단일 물리 볼륨의 남은 공간보다 적다면, 논리 볼륨의 모든 공간을 (단일) 물리 볼륨에 연속적인 형태로 위치하도록 합니다. 이러한 조치는 성능상 이유로 처리됩니다.

볼륨 그룹에서 물리 볼륨을 제거해야 한다면, 물리 볼륨에서 데이터를 먼저 이동해야 합니다. 명령을 사용하면, 동일한 볼륨 그룹 내에서 물리 볼륨의 모든 데이터를 다른 물리 볼륨으로 이동합니다.

이런 과정은 옮겨야 하는 데이터의 양에 따라 시간이 걸릴 수 있습니다. 이 과정이 끝나면, 장치에 남은 데이터가 없어야 합니다. 명령으로 물리 볼륨을 어떤 논리 볼륨에서도 더 이상 사용하지 않는지 확인하십시오.

다음 단계는  명령으로 볼륨 그룹에서 물리 볼륨을 제거할 차례이며,   명령으로 물리 볼륨의 선택을 해제 할 수 있습니다.

VG(볼륨 그룹)
볼륨 그룹(VG)은 수많은 물리 볼륨을 묶고 장치 파일 시스템에 와 같은 식으로 보여줍니다. 볼륨 그룹의 이름은 관리자가 선택합니다.

VG 만들기
다음 명령은 과 물리 볼륨을 묶어 vg0이라 하는 볼륨 그룹을 만듭니다.

VG 목록 표시
모든 활성화 볼륨 그룹의 목록을 표시하려면,  명령을 사용하십시오:

볼륨 그룹이 빠져있으면 볼륨 그룹을 찾아 가리키는  명령을 사용하십시오:

VG 확장
볼륨 그룹은 관리자가 파일 시스템에 할당하는 저장소 자원 풀을 사용하도록 하며, 물리 볼륨을 묶습니다. 볼륨 그룹이 충분한 저장소 자원을 가지지 않았다면, 추가 물리 볼륨에 대해 볼륨 그룹을 확장할 필요가 있습니다.�

다음 예제 에서는 vg0 그룹을  물리 볼륨으로 확장합니다:

물리 볼륨을 각각 준비해야 함을 기억하십시오!

VG 줄이기
논리 볼륨을 볼륨 그룹에서 제거해야 한다면, 물리 볼륨에서 사용중인 모든 데이터를 볼륨 그룹의 다른 물리 볼륨으로 이동해야 합니다. 앞에서 보신 바와 같이,  명령으로 처리할 수 있으며, 그 다음에   명령으로 볼륨 그룹에서 물리 볼륨을 제거할 수 있습니다:

VG 제거
볼륨 그룹이 더이상 필요하지 않다면(또는, 다른 말로, 저장소 풀을 더이상 사용하지 않으며, 다른 목적으로 물리 볼륨을 해제해야 할 경우),   명령으로 볼륨 그룹을 제거할 수 있습니다. 볼륨 그룹에 정의한 논리 볼륨이 없고 하나의 완전한 물리 볼륨을 풀에서 제거 했을 경우에만 동작합니다.

LV(논리 볼륨)
논리 볼륨은 시스템에 존재하는 최종 메타 장치이며, 보통 파일 시스템에 만듭니다. 볼륨 그룹에 만들고 관리하며 형식으로 나타납니다. 볼륨 그룹처럼, 논리 볼륨에 사용하는 이름은 관리자가 결정합니다.

LV 만들기
논리 볼륨을 만들려면  명령을 사용합니다. 명령의 매개 변수는 논리 볼륨에 요청하는 크기(볼륨 그룹의 남은 공간 용량보다 클 수 없음), 요청한 볼륨 그룹, 만들 논리 볼륨 공간의 이름으로 구성됩니다.

다음 예제에서는 vg0 볼륨 그룹에 150MB 용량의 lvol1 논리 볼륨을 만듭니다:

명령으로 볼륨 그룹 내의 모든 남은 용량을 사용하도록 할 수 있습니다. (판독할 수 있는) 크기를 적기보다는 확장 용량 모두를 선택하는 -l 매개 변수로 처리할 수 있습니다. 논리 볼륨은 볼륨 그룹 내의 데이터 덩어리인 논리 확장으로 나뉩니다. 모든 논리 그룹의 확장은 동일한 크기를 갖습니다. -l 매개 변수를 활용하면  명령으로 전체 남은 확장 공간을 할당하도록 요청할 수 있습니다.

FREE 다음에 VG 키를 사용하여 볼륨 그룹의 전체 크기를 표시할 수 있습니다.

LV 목록 표시
모든 논리 볼륨 내용을 표시하려면  명령을 사용하십시오:

논리 볼륨이 빠져있다면,  명령으로 존재하는 모든 볼륨 그룹의 논리 볼륨을 검색할 수 있습니다.

LV 확장
논리 볼륨을 확장하려면,  명령으로 논리 볼륨에 할당한 공간을 늘릴 수 있습니다.

가령, 논리 볼륨 lvol1의 전체 용량을 500MB로 확장하려면:

전체 용량보다 더 큰 용량을 추가할 수도 있습니다:

확장 볼륨 그룹은 최종 사용자에게 추가 저장소로서 바로 제공할 수 없습니다. 그렇기에, 볼륨 그룹의 최상단에 있는 파일 시스템을 마찬가지로 늘려야 합니다. 마운트한 상태에서 모든 파일 시스템의 크기를 조정할 수 있는 것은 아니기에, 파일 시스템의 궁금증에 대해 더 많은 내용을 살펴보려면 문서를 확인하십시오.

가령, ext4 파일 시스템ㅁ의 크기를 500MB 크기로 조절하려면:

LV 줄이기
논리 볼륨의 크기를 줄여야 한다면, 먼저 파일 시스템 자체의 크기를 줄이십시오. 모든 파일 시스템이 마운트한 상태에서 용량 줄이기 기능을 지원하는 것은 아닙니다.

가령, ext4는 마운트한 상태에서 용량 줄이는 기능을 지우너하지 않으므로, 먼저 파일 시스템의 마운트를 해제해야합니다. 그리고 파일 시스템을 검사하여 파일 시스템의 무결성 확인을 추천합니다:

용량이 줄어든 파일 시스템을 통해, 마찬가지로, 이제 논리 볼륨의 용량을 줄일 수 있습니다:

LV 사용 권한
LVM에서는 논리 볼륨에 대해 권한 상태 조정 기능을 지원합니다.

가령,  명령으로 논리 볼륨을 읽기 전용 상태로 설정할 수 있습니다:

바뀐 내용을 즉시 강제로 적용하지 않았기 때문에 다시 마운트해야 합니다.

논리 볼륨을 쓰기 가능상태로 다시 처리하려면 rw 퍼미션 비트를 사용하십시오:

LV 제거
논리 볼륨을 제거하기 전에 더이상 마운트한 볼륨이 없는지 확인하십시오:

논리 볼륨을 비활성화하여 더이상 쓰기 동작을 할 수 없게 하십시오:

볼륨 마운트를 해제하여 비활성화 하면, 이제 제거하고, 볼륨 그룹에서 다른 논리 볼륨이 사용하도록 확장 할당을 해제할 수 있습니다.

기능
LVM provides quite a few interesting features for storage administrators, including (but not limited to)
 * thin provisioning (over-committing storage)
 * snapshot support
 * volume types with different storage allocation methods

씬 관리
LVM2 최근 버전(2.02.89)에서는 씬 볼륨을 지원합니다. 씬 볼륨은 파일 시스템에 파일이 드문드문 분산해서 들어가는 블록 장치입니다. 따라서, 풀에 있는 씬 논리 볼륨은 오버 커밋 이 가능합니다. 즉, 할당한 크기보다 나타난 크기가 클 수는 있습니다. 풀 자체 크기보다 클 수도 있습니다. 드문드문 분산된 파일 처럼, 확장체는 블록 장치로 할당됩니다. 파일을 제거했을 때 다시 빈 공간이 늘어나 남은 영역을 파일 시스템에서 버리는 기능을 지원한다면 풀의 공간 가용성이 줄어듭니다.

LVM에서 각각의 씬 풀은 특별한 형식의 논리 볼륨이며, 논리 볼륨을 자체적으로 제공할 수 있습니다.

씬 풀 만들기
각각의 씬 풀에는 관련 메타데이터가 있으며, 씬 풀 용량에 추가됩니다. LVM에서는 크기가 어떻게 되든지간에 최소한 pool_chunks * 64 bytes 또는 2MiB 만큼 씬 풀 크기를 기반으로 메타데이터 크기를 계산합니다. 관리자는 마찬가지로 메타데이터 크기를 달리 선택할 수 있습니다.

씬 풀을 만들려면  명령에 --type thin-pool --thinpool thin_pool 매개변수를 추가하십시오:

위의 예제에서는 thin_pool을 총 150MB의 용량으로 만듭니다. 150MB는 씬 풀에 실제 할당한 크기입니다(그렇기 때문에 실제 저장소에서 활용할 수 있는 전체 공간이 됩니다).

각각의 메타데이터 크기를 분명하게 요청하려면 --metadatasize 매개변수를 사용하십시오:

씬 풀에 추가한 메타데이터 때문에, 볼륨 그룹에서 논리 볼륨에 대해 사용 가능한 전체 공간을 활용하는 직관적인 방법이 먹혀들지 않습니다(LVM 버그 |812726 참고).

씬 풀에는 다른 LV의 노드처럼 관련 장치 노드가 있는것이 아닙니다.

씬 논리 볼륨 만들기
씬 논리 볼륨은 씬 풀에 있는 논리 볼륨입니다(씬 풀 자체는 논리 볼륨입니다). 씬 논리 볼륨이 듬성듬성 하기에, -V 매개 변수로 물리 크기 대신 가상 크기를 설정합니다:

이 예제에서, 실제 할당한 저장소의 크기가 150MB라 하더라도, (씬) 논리 볼륨 lvol1은 300MB 크기의 장치로 나타납니다.

씬 풀의 논리 볼륨처럼 각각의 씬 풀을 하나의 명령으로 만들 수 있습니다:

씬 풀과 씬 논리 볼륨 목록 표시
씬 풀과 씬 논리 볼륨은 논리 볼륨의 특별한 형식이며,  명령으로 표시합니다. 명령은 이들 논리 볼륨도 감지합니다.

씬 풀 확장
명령을 사용하면 씬 논리 볼륨이 아닌 다른 볼륨처럼 확장할 수 있습니다. 예를 들면 다음과 같습니다:

씬 논리 볼륨 확장
씬 논리 볼륨은 보통 논리 볼륨처럼 확장됩니다:

Note that the  command uses the -L option (or -l if extent counts are used) and not a "virtual size" option as was used during the creation.

씬 풀 줄이기
Currently, LVM cannot reduce the size of the thin pool. See LVM bug |812731.

Reducing a thin logical volume
Thin logical volumes are reduced just like regular logical volumes.

For instance:

명령은 -L 옵션(또는 확장 카운트를 사용할 경우 -l)을 사용하며, 만들기 과정에 사용한 가상 크기 옵션은 아님에 유의하십시오.

씬 풀 제거
씬 풀은 내부에 있는 모든 씬 논리 볼륨을 제거하기 전까지는 제거할 수 없습니다.

씬 풀에서 더 이상 어떤 씬 논리 볼륨을 제공하지 않는다면, 명령으로 제거할 수 있습니다:

LVM2 스냅샷과 씬 스냅샷
스냅샷은 다른 논리 볼륨의 사본처럼 동작하는 논리 볼륨입니다. 스냅샷을 만든 횟수만큼 원래 논리 볼륨의 상태를 나타냅니다.

스냅샷 논리 볼륨 만들기
A snapshot logical volume is created using the -s option to. Snapshot logical volumes are still given allocated storage as LVM "registers" all changes made to the original logical volume and stores these changes in the allocated storage for the snapshot. When querying the snapshot state, LVM will start from the original logical volume and then check all changes registered, "undoing" the changes before showing the result to the user.

A snapshot logical volume henceforth "growths" at the rate that changes are made on the original logical volume. When the allocated storage for the snapshot is completely used, then the snapshot will be removed automatically from the system.

The above example creates a snapshot logical volume called 20140412_lvol1, based on the logical volume lvol1 in volume group vg0. It uses 10% of the space (extents actually) allocated to the volume group.

Accessing a snapshot logical volume
Snapshot logical volumes can be mounted like regular logical volumes. They are even not restricted to read-only operations - it is possible to modify snapshots and thus use it for things such as testing changes before doing these on a "production" file system.

As long as snapshot logical volumes exist, the regular/original logical volume cannot be reduced in size or removed.

LVM thin snapshots
To create a thin snapshot, the  command is used with the   option. No size declaration needs to be passed on:

Thin logical volume snapshots have the same size as their original thin logical volume, and use a physical allocation of 0 just like all other thin logical volumes.

It is also possible to take snapshots of snapshots:

Thin snapshots have several advantages over regular snapshots. First, thin snapshots are independent of their original logical volume once created. The original logical volume can be shrunk or deleted without affecting the snapshot. Second, thin snapshots can be efficiently created recursively (snapshots of snapshots) without the "chaining" overhead of regular recursive LVM snapshots.

Rolling back to snapshot state
To rollback the logical volume to the version of the snapshot, use the following command:

볼륨의 크기에 따라 몇 분 걸릴 수도 있습니다.

Rolling back thin snapshots
For thin volumes,  does not work. Instead, delete the original logical volume and rename the snapshot:

Different storage allocation methods
LVM supports different allocation methods for storage:
 * linear volumes (which is the default)
 * mirrored volumes (in a more-or-less active/standby setup)
 * striping (RAID0)
 * mirrored volumes (RAID1 - which is more an active/active setup)
 * striping with parity (RAID4 and RAID5)
 * striping with double parity (RAID6)
 * striping and mirroring (RAID10)

Linear volumes
Linear volumes are the most common kind of LVM volumes. LVM will attempt to allocate the logical volume to be as physically contiguous as possible. If there is a physical volume large enough to hold the entire logical volume, then LVM will allocate it there, otherwise it will split it up into as few pieces as possible.

The commands introduced earlier on to create volume groups and logical volumes create linear volumes.

Because linear volumes have no special requirements, they are the easiest to manipulate and can be resized and relocated at will. If a logical volume is allocated across multiple physical volumes, and any of the physical volumes become unavailable, then that logical volume cannot be started anymore and will be unusable.

Mirrored volumes
LVM supports mirrored volumes, which provide fault tolerance in the event of drive failure. Unlike RAID1, there is no performance benefit - all reads and writes are delivered to a single side of the mirror.

To keep track of the mirror state, LVM requires a log to be kept. It is recommended (and often even mandatory) to position this log on a physical volume that does not contain any of the mirrored logical volumes. There are three kind of logs that can be used for mirrors:


 * 1) Disk is the default log type. All changes made are logged into extra metadata extents, which LVM manages. If a device fails, then the changes are kept in the log until the mirror can be restored again.
 * 2) Mirror logs are disk logs that are themselves mirrored.
 * 3) Core mirror logs record the state of the mirror in memory only. LVM will have to rebuild the mirror every time it is activated. This type is useful for temporary mirrors.

To create a logical volume with a single mirror, pass the -m 1 argument (to select standard mirroring) with optionally --mirrorlog to select a particular log type:

The -m 1 tells LVM to create one (additional) mirror, so requiring 2 physical volumes. The --nosync option is an optimization - without it LVM will try synchronize the mirror by copying empty sectors from one logical volume to another.

It is possible to create a mirror of an existing logical volume:

The -b option does the conversion in the background as this can take quite a while.

To remove a mirror, set the number of mirrors (back) to 0:

If part of the mirror is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

On the first write, LVM will notice the mirror is broken. The default policy ("remove") is to automatically reduce/break the mirror according to the number of pieces available. A 3-way mirror with a missing physical volume will be reduced to 2-way mirror; a 2-way mirror will be reduced to a regular linear volume. If the failure is only transient, and the missing physical volume returns after LVM has broken the mirror, the mirrored logical volume will need to be recreated on it.

To recover the mirror, the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on that one). Then the mirror can be recreated with lvconvert at which point the old physical volume can be removed from the volume group:

It is possible to have LVM recreate the mirror with free extents on a different physical volume if one side fails. To accomplish that, set  to allocate in.

Thin mirrors
It is not (yet) possible to create a mirrored thin pool or thin volume. It is possible to create a mirrored thin pool my creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Striping (RAID0)
Instead of a linear volume, where multiple contiguous physical volumes are appended, it possible to create a striped or RAID 0 volume for better performance. This will alternate storage allocations across the available physical volumes.

To create a striped volume over three physical volumes:

The -i option indicates over how many physical volumes the striping should be done.

It is possible to mirror a stripe set. The -i and -m options can be combined to create a striped mirror:

This creates a 2 physical volume stripe set and mirrors it on 2 different physical volumes, for a total of 4 physical volumes. An existing stripe set can be mirrored with lvconvert.

A thin pool can be striped like any other logical volume. All the thin volumes created from the pool inherit that settings - do not specify it manually when creating a thin volume.

It is not possible to stripe an existing volume, nor reshape the stripes across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set can be mirrored. It is possible to extend a stripe set across additional physical volumes, but they must be added in multiples of the original stripe set (which will effectively linearly append a new stripe set).

Mirroring (RAID1)
Unlike RAID 0, which is striping, RAID 1 is mirroring, but implemented differently than the original LVM mirror. Under RAID1, reads are spread out across physical volumes, improving performance. RAID1 mirror failures do not cause I/O to block because LVM does not need to break it on write.

Any place where an LVM mirror could be used, a RAID 1 mirror can be used in its place. It is possible to have LVM create RAID1 mirrors instead of regular mirrors implicitly by setting mirror_segtype_default to raid1 in.

To create a logical volume with a single mirror:

Note the difference for creating a mirror: There is no mirrorlog specified, because RAID1 logical volumes do not have an explicit mirror log - it built-in to the logical volume.

It is possible to convert an existing logical volume to RAID 1:

To remove a RAID 1 mirror, set the number of mirrors to 0:

If part of the RAID1 is unavailable (usually because the disk containing the physical volume has failed), the volume group will need to be brought up in degraded mode:

Unlike an LVM mirror, writing does NOT breaking the mirroring. If the failure is only transient, and the missing physical volume returns, LVM will resync the mirror by copying cover the out-of-date segments instead of the entire logical volume. If the failure is permanent, then the failed physical volume needs to be removed from the volume group, and a replacement physical volume needs to be added (or if the volume group has a free physical volume, it can be created on a different PV). The mirror can then be repaired with lvconvert, and the old physical volume can be removed from the volume group:

Thin RAID1
It is not (yet) possible to create a RAID 1 thin pool or thin volume. It is possible to create a RAID 1 thin pool by creating a normal mirrored logical volume and then converting the logical volume to a thin pool with lvconvert. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will then merge them into a single logical volume.

Striping with parity (RAID4 and RAID5)
RAID 0 is not fault-tolerant - if any of the physical volumes fail then the logical volume is unusable. By adding a parity stripe to RAID 0 the logical volume can still function if a physical volume is missing. A new physical volume can then be added to restore fault tolerance.

Stripsets with parity come in 2 flavors: RAID 4 and RAID 5. Under RAID 4, all the parity stripes are stored on the same physical volume. This can become a bottleneck because all writes hit that physical volume, and it gets worse the more physical volumes are in the array. With RAID 5, the parity data is distributed evenly across the physical volumes so none of them become a bottleneck. For that reason, RAID 4 is rare and is considered obsolete/historical. In practice, all stripesets with parity are RAID 5.

Only the data physical volumes are specified with -i, LVM adds one to it automatically for the parity. So for a 3 physical volume RAID5, -i 2 is passed on and not -i 3.

When a physical volume fails, then the volume group will need to be brought up in degraded mode:

The volume will work normally at this point, however this degrades the array to RAID 0 until a replacement physical volume is added. Performance is unlikely to be affected while the array is degraded - although it does need to recompute its missing data via parity, it only requires simple XOR for the parity block with the remaining data. The overhead is negligible compared to the disk I/O.

To repair the RAID5:

It is possible to replace a still working physical volume in RAID5 as well:

The same restrictions of stripe sets apply to stripe sets with parity as well: it is not possible to enable striping with parity on an existing volume, nor reshape the stripes with parity across more/less physical volumes, nor to convert to a different RAID level/linear volume. A stripe set with parity can be mirrored. It is possible to extend a stripe set with parity across additional physical volumes, but they must be added in multiples of the original stripe set with parity (which will effectively linearly append a new stripe set with parity).

Thin RAID5 logical volumes
It is not (yet) possible to create stripe set with parity (RAID5) thin pools or thin logical volumes. It is possible to create a RAID5 thin pool by creating a normal RAID5 logical volume and then converting the logical volume into a thin pool with lvconvert</tt>. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Striping with double parity (RAID6)
RAID 6 is similar to RAID 5, however RAID 6 can survive up to two physical volume failures, thus offering more fault tolerance than RAID5 at the expense of extra physical volumes.

Like raid5, the -i option is used to specify the number of physical volumes to stripe, excluding the 2 physical volumes for parity. So for a 5 physical volume RAID6, pass on -i 3 and not -i 5.

Recovery for RAID6 is the same as RAID5.

Thin RAID6 logical volumes
It is not (yet) possible to create a RAID6 thin pool or thin volumes. It is possible to create a RAID6 thin pool by creating a normal RAID6 logical volume and then converting the logical volume into a thin pool with lvconvert</tt>. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

LVM RAID10
RAID10 is a combination of RAID0 and RAID1. It is more powerful than RAID0+RAID1 as the mirroring is done at the stripe level instead of the logical volume level, and therefore the layout doesn't need to be symmetric. A RAID10 volume can tolerate at least a single missing physical volume, and possibly more.

Both the -i and -m options are specified: -i is the number of stripes and -m is the number of mirrors. Two stripes and 1 mirror requires 4 physical volumes.

Thin RAID10
It is not (yet) possible to create a RAID10 thin pool or thin volumes. It is possible to create a RAID10 thin pool by creating a normal RAID10 logical volume and then converting the logical volume into a thin pool with. 2 logical volumes are required: one for the thin pool and one for the thin metadata; the conversion process will merge them into a single logical volume.

Experimenting with LVM
It is possible to experiment with LVM without using real storage devices. To accomplish this, loopback devices are created.

First make sure to have the loopback module loaded.

Next configure LVM to not use udev to scan for devices:

Create some image files which will become the storage devices. The next example uses five files for a total of about ~10GB of real hard drive space:

Check which loopback devices are available:

Assuming all loopback devices are available, next create the devices:

The devices are now available to use as any other hard drive in the system (and thus be perfect for physical volumes).

Troubleshooting
LVM has a few features that already provide some level of redundancy. However, there are situations where it is possible to restore lost physical volumes or logical volumes.

vgcfgrestore utility
By default, on any change to a LVM physical volume, volume group, or logical volume, LVM2 create a backup file of the metadata in. These files can be used to recover from an accidental change (like deleting the wrong logical volume). LVM also keeps a backup copy of the most recent metadata in. These can be used to restore metadata to a replacement disk, or repair corrupted metadata.

To see what states of the volume group are available to be restored (partial output to improve readability):

Recovering an accidentally deleted logical volume
Assuming the logical volume lvm_raid1 was accidentally removed from volume group vg0, it is possible to recover it as follows:

Replacing a failed physical volume
It possible to do a true "replace" and recreate the metadata on the new physical volume to be the same as the old physical volume:

The important line here is the UUID "unknown device".

This recreates the physical volume metadata, but not the missing logical volume or volume group data on the physical volume.

This now reconstructs all the missing metadata on the physical volume, including the logical volume and volume group data. However it doesn't restore the data, so the mirror is out of sync.

This will resync the mirror. This works with RAID 4,5 and 6 as well.

Deactivating a logical volume
It is possible to deactivate a logical volume with the following command:

It is not possible to mount the logical volume anywhere before it gets reactivated:

External resources

 * LVM2 sourceware.org
 * LVM tldp.org
 * LVM2 Wiki redhat.com