-
Notifications
You must be signed in to change notification settings - Fork 0
/
clvm.txt
94 lines (76 loc) · 7 KB
/
clvm.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
-=(CLVM and GPT)=-
-(
Content:
1. LVM
.1 Layout
.2 Usage
.3 Labels and Metadata
.4 CLVM
2. EFI
.1 GPT
A Sources
)-
-( 1. ---[ LVM ]---
Logical Volume Management adds fast and reliable abstraction layer on top of classical partitions. LVM provides a means to concatenate, stripe together or otherwise combine partitions into larger virtual ones that administrators can re-size or move, potentially without interrupting system use. Logical partitions are not limited to size of physical disks. LVM also allows mirroring and snapshots.
-( 1.1 ---[ Layout ]---
+-----------------------------+
|Logical Volume|Logical Volume|
|LE|LE|LE|LE|LE|LE|LE|LE|LE|LE|
|-----------------------------|
| Volume Group |
|-------------------_---------|
| Physical Volume Group |
+-----------------------------+
___________________________|___________________________
/ / \ \
|PE|PE|PE|PE|PE|PE|PE|PE|PE| |PE|PE|PE|PE|PE|PE|PE|PE|PE|
| Physical Volume | | Physical Volume |
|--------------------------| |--------------------------|
| HDD or partition or LUN | | HDD or partition or LUN |
+--------------------------+ +--------------------------+
LVM layout consists of three logical types: Physical Volume, Volume Group, Logical Volume. Physical Volume (PV) represents real hardware - block device (hard disk, partition or LUN). PVs are divided into small pieces - Physical Extents (PE) and can be grouped into groups - Physical Volume Groups (PVG). PVGs are grouped together into Volume Groups (VG) which are divided into small pieces of Logical Extents (LE). LEs grouped together form Logical Volumes (LV). LVs represent raw block devices to running system. Grouping PVs into PVGs allows mapping one LE on more than one PE which allows mirroring, online transferring data on physical devices and so on.
-( 1.2 ---[ Usage ]---
pvcreate <block devices> creating PVs
pvremove <block device> removing PVs
pvscan scans all disks for PVs
pvdisplay displays PVs
vgcreate <VG name> <block devices> creates VG from PVs
vgremove <VG name> removes VG
vgreduce <VG name> <block devices> migrates data off selected PV and removes it from VG
vgscan scans all disks for VGs and rebuilds caches
vgdisplay displays VGs
lvcreate -n <name> -L <size> <VG name> creates LV
lvremove <LV> removes LV
lvreduce -L <size> <LV> reduces LV
lvextend -L <size> <LV> extends LV
lvscan scans for LVs
lvdisplay displays LVs
-( 1.3 ---[ Labels and Metadata ]---
PVs are created by putting Label on usually second 512byte sector, but can be on any of first four sectors. Label stores name, uuid, size in bites and location of metadata. Metadata are stored in ASCII, contain configuration information about VG and are identical on each PV in same VG. As metadata copies on huge VGs cause high overhead costs LVN is often used in setup where only original metadata is stored on PV. This is done by providing "metadatacopies 0" option to "pvcreate" on creation of PVs. One can read LVN metadata from raw disk by running "strings /dev/disk | grep "# Generated by LVMA 2048 >output.txt" where metadata size may bigger on big VGs so one has to increase size to 2048+k*1024.
-( 1.4 ---[ CLVM ]---
Problems start while using LVN on clusters. This comes from multiple access to metadata which has to be resolved by locking mechanism. While high availability clusters don't require locking as only one machine is accessing device at the time it's preferred to use HaLVM and for normal clusters there is solution for locking by using clvmd daemon. CLVM is LVM extension which adds locking of PE during the access.
For CLVM to work with Red Hat Cluster Suite one has to have running cluster and turn on clvmd (chkconfig clvmd on;), change LVM locking mechanism, check that all nodes in cluster have access to PVs and it's done. Work with CLVM is nearly the same as with normal LVM. Change of locking mechanism is done by running "/sbin/lvmconf –enable-cluster" or change in "/etc/lvm/lvm.conf" option "locking = 3" has to be set. By this LVM will use built in dlm mechanism. To check if clvmd is working correctly one can run "cman tool servicies", output should contain "DLM (Distributed Lock Manager) lockspaces - clvmd".
-( 2. ---[ EFI ]---
UEFI (Unified Extensible Firmware Interface) is a specification developed by Intel to become replacement for older BIOS firmware interface in PCs. UEFI is not restricted to any specific processor architecture, and can run on top of or instead of traditional BIOS implementations. EFI is often criticized for adding bigger complexity over the feautres compared to OpenBIOS or Coreboot. UEFI consists of:
Disk support - new partitioning scheme with GPT
Processor support - access to all of the memory in pre-boot environment by removing old BIOS limitations
Services - boot and runtime services
Protocols - protocols defining interfaces for communication between binary modules
Device drivers - EFI provides processor-independent device driver environment (EBC) similar to OpenFirmware
Boot Management - attempt to remove need for a dedicated boot loader mechanism
The EFI shell - shell environment to execute EFI applications
Extensions - ability to load extensions from any non-volatile storage device attached to the computer
-( 2.1 ---[ GPT ]---
The MBR partitioning system created in 1980s hits it's limitations and inorder to replace it Intel created GPT (GUID Partition Types) as part of EFI. GPT uses logical block addressing (LBA) instead of cylinder/head/sector (CHS). Disk pointers are 64bit allowing 9.4ZB size. Critical GPT data structures are stored twice on the disk: once at the start and again at the end. GPT uses CRC to improve corruption detection. GPT allows 128 partitions and stores them all in single partition table. GPT uses GUIS to identify partition types. GPT also adds partition labels and is somewhat backwards compatible by using "gptsync" to fake MBR. Usual partitioning tool "fdisk" does not support GPT so one has to use "parted" which is more robust and actually should be preferred over fdisk. In parted GPT is turned on by running "mklabel". There should be full support for GPT in modern Linux distributions by now, for example Fedora should boot without problems since F13.
-( A ---[Sources]---
http://{cs,en}.wikipedia.org/wiki/Logical_Volume_Management
http://www.howtoforge.com/linux_lvm
http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/physical_volumes.html
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
http://cs.wikipedia.org/wiki/Extensible_Firmware_Interface
http://en.wikipedia.org/wiki/GUID_Partition_Table
https://bugzilla.redhat.com/show_bug.cgi?id=518477
https://bugzilla.redhat.com/show_bug.cgi?id=604182
https://bugzilla.redhat.com/show_bug.cgi?id=694808
https://bugzilla.redhat.com/show_bug.cgi?id=467848
http://www.ibm.com/developerworks/linux/library/l-gpt/index.html?ca=dgr-lnxw97GPT-Storagedth-lx&S_TACT=105AGY83&S_CMP=grlnxw97