В наши дни управлять томами в Linux — совершенно тривиальная задача, которая не вызывает в инженере ни чувства азарта, ни жажды исследования. Наборами команд, инструкциями по созданию томов и снэпшотов — ими же кишит весь интернет. Тем не менее, беспокойный инженерный ум требует разобраться, как же это работает под капотом. А происходит это весьма интересно. Но для начала, как обычно, позвольте небольшую историческую справку (на 40 минут). Приятного чтения :-)
Как было раньше?
Если мы отмотаем время назад и посмотрим, как выглядела работа с дисками в ее первозданном виде (когда деревья были высокими, а трава зеленее), то здесь сюрпризов нет: блочное устройство разделяется на партиции, на них создается файловая система (или не создается –– работа с блочными устройствами такая же неотъемлемая часть Linux).
На этом этапе нам интересно освежить несколько моментов:
Момент 1
Если мы выполняем ls для блочных устройств, то там видны пары цифр:
# ls -la /dev/sda*
brw-rw----. 1 root disk 8, 0 Apr 18 11:54 /dev/sda
brw-rw----. 1 root disk 8, 1 Apr 18 11:54 /dev/sda1
brw-rw----. 1 root disk 8, 2 Apr 18 11:54 /dev/sda2
brw-rw----. 1 root disk 8, 3 Apr 18 11:54 /dev/sda3Это не что иное как, пара major и minor номера. Major указывает на драйвер, работающий с данным устройством, а minor — порядковый номер устройства:
# grep sd /proc/devices
8 sd
65 sd
66 sd
. . . . Момент 2
Из этого происходит и полное имя блочного устройства:
sd — имя драйвера;
a — порядковый номер диска;
1, 2, 3, 4… — порядковый номер партиции.
Момент 3
Если мы посмотрим на диски пристальнее, то заметим: на каждое блочное устройство резервируется 15 minor-номеров. Один — на имя всего диска, остальные — под партиции:
[root@cluster-2 ~]# ls -la /dev/sd*
brw-rw----. 1 root disk 8, 0 Apr 18 11:54 /dev/sda
brw-rw----. 1 root disk 8, 1 Apr 18 11:54 /dev/sda1
brw-rw----. 1 root disk 8, 2 Apr 18 11:54 /dev/sda2
brw-rw----. 1 root disk 8, 3 Apr 18 11:54 /dev/sda3
brw-rw----. 1 root disk 8, 16 Apr 18 11:54 /dev/sdb
brw-rw----. 1 root disk 8, 32 Apr 18 11:54 /dev/sdc
brw-rw----. 1 root disk 8, 48 Apr 18 11:54 /dev/sdd
brw-rw----. 1 root disk 8, 64 Apr 18 11:54 /dev/sde
brw-rw----. 1 root disk 8, 80 Apr 18 11:54 /dev/sdf
brw-rw----. 1 root disk 8, 96 Apr 18 11:54 /dev/sdg
brw-rw----. 1 root disk 8, 112 Apr 18 11:54 /dev/sdhПочему резервируется столько minor-номеров, если можно создать только четыре primary-партиции? Это связано с extended-партициями. Причем если рассматривать их максимальное количество, то вопрос «Почему так много?» сменяется противоположным «Почему так мало?». Добавим еще один диск и посмотрим, что же можно «выжать» из него:
# ls -la /dev/sd*
brw-rw----. 1 root disk 8, 0 Apr 18 11:54 /dev/sda
brw-rw----. 1 root disk 8, 1 Apr 18 11:54 /dev/sda1
brw-rw----. 1 root disk 8, 2 Apr 18 11:54 /dev/sda2
brw-rw----. 1 root disk 8, 3 Apr 18 11:54 /dev/sda3
brw-rw----. 1 root disk 8, 16 Apr 18 11:54 /dev/sdb
brw-rw----. 1 root disk 8, 32 Apr 18 11:54 /dev/sdc
brw-rw----. 1 root disk 8, 48 Apr 18 11:54 /dev/sdd
brw-rw----. 1 root disk 8, 64 Apr 18 11:54 /dev/sde
brw-rw----. 1 root disk 8, 80 Apr 18 11:54 /dev/sdf
brw-rw----. 1 root disk 8, 96 Apr 18 11:54 /dev/sdg
brw-rw----. 1 root disk 8, 112 Apr 18 11:54 /dev/sdh
brw-rw----. 1 root disk 8, 128 Apr 21 18:38 /dev/sdiНачинаем делать extended-партиции и видим, что список minor-номеров продлился:
# ls -la /dev/sdi*
brw-rw----. 1 root disk 8, 128 Apr 21 18:55 /dev/sdi
brw-rw----. 1 root disk 8, 129 Apr 21 18:55 /dev/sdi1
brw-rw----. 1 root disk 8, 138 Apr 21 18:55 /dev/sdi10
brw-rw----. 1 root disk 8, 139 Apr 21 18:55 /dev/sdi11
brw-rw----. 1 root disk 8, 140 Apr 21 18:55 /dev/sdi12
brw-rw----. 1 root disk 8, 141 Apr 21 18:55 /dev/sdi13
brw-rw----. 1 root disk 8, 142 Apr 21 18:55 /dev/sdi14
brw-rw----. 1 root disk 8, 143 Apr 21 18:55 /dev/sdi15
brw-rw----. 1 root disk 259, 4 Apr 21 18:55 /dev/sdi16
brw-rw----. 1 root disk 259, 5 Apr 21 18:55 /dev/sdi17
brw-rw----. 1 root disk 259, 6 Apr 21 18:55 /dev/sdi18
brw-rw----. 1 root disk 259, 7 Apr 21 18:55 /dev/sdi19
brw-rw----. 1 root disk 8, 130 Apr 21 18:55 /dev/sdi2
brw-rw----. 1 root disk 8, 131 Apr 21 18:55 /dev/sdi3
brw-rw----. 1 root disk 8, 132 Apr 21 18:55 /dev/sdi4
brw-rw----. 1 root disk 8, 133 Apr 21 18:55 /dev/sdi5
brw-rw----. 1 root disk 8, 134 Apr 21 18:55 /dev/sdi6
brw-rw----. 1 root disk 8, 135 Apr 21 18:55 /dev/sdi7
brw-rw----. 1 root disk 8, 136 Apr 21 18:55 /dev/sdi8
brw-rw----. 1 root disk 8, 137 Apr 21 18:55 /dev/sdi9И их максимальное количество может быть 60. В исходном коде драйвера sd есть строки, описывающие механизм резервации:
Inside a major, we have 16k disks, however mapped non-
* contiguously. The first 16 disks are for major0, the next
* ones with major1, ... Disk 256 is for major0 again, disk 272
* for major1, ...
* As we stay compatible with our numbering scheme, we can reuse
* the well-know SCSI majors 8, 65--71, 136--143.
*/Момент 4
Раньше мы могли создать достаточно большое количество партиций и решить проблему c делением диска классическим способом.
Примечание: Не забываем про динамическую природу именования устройств в Linux. В зависимости от последовательности, в которой ОС инициализировала устройства, их имена могут изменяться. И так то, что было, например, /dev/sdi, станет /dev/sdb, а после очередной перезагрузки — наоборот.
Как решили проблему объединения
Но что если нам, наоборот, нужно объединить несколько дисков в одно большое блочное устройство?
Итак, теперь мы решаем задачу объединения. Можно закрыть много вопросов аппаратным RAID-контроллером, но это слишком просто и, относительно 0 рублей, затрачиваемых на Software-RAID, дорого.
Долгое время штатным решением считалось использование модуля md (multiple devices) и создание, например, конкатенации (concatenation).
Примечание автора: иногда stripe и concat относят к RAID0 (например, в Solaris):
# mdadm --create --verbose /dev/md0 --level=linear --raid-devices=2 /dev/sdi1 /dev/sdi2
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.Посмотрим на получившееся устройство:
# ls -la /dev/md0
brw-rw----. 1 root disk 9, 0 Apr 22 14:03 /dev/md0А кто же обслуживает major под номером 9?
# grep md /proc/devices
9 md
254 mdpВроде эту задача решили, и можно так жить дальше. Расходимся. К нашей радости, ИТ-мир гораздо более сознателен и не останавливается на половине пути, за что мы его и любим.
Logical Volume Manager (LVM)
В «кровавом Enterprise» работа с дисками давно была организована на принципиально новом уровне, но за деньги:
1) Мы могли разметить диски для использования LVM (инициализировать их).
2) Диски объединялись в логические группы на основании, например, приложения, работающего с ними (дисковые группы).
3) В этих логических группах создавались уже сами тома различной логики (RAID, размещение на дисках с учетом местоположения дисков на SCSI-контроллерах).
Решить все перечисленные задачи в Linux стало возможно с помощью карты device-mapper.
Примечание: device-mapper — это модуль ядра, предоставляющий фреймворк для работы с дисковыми устройствами. На основании этих карт LVM создает свои устройства.
Чем же занимается device-mapper? Он может из «кусков» блочных устройств создавать новое виртуальное устройство, которое для ОС выглядит как совершенно обычное блочное устройство. Работает это следующим образом: приложения/команды используют библиотеку libdevmapper, которая при помощи команд ioctl передает данные в устройство /dev/mapper/control
# strace dmsetup ls
execve("/usr/sbin/dmsetup", ["dmsetup", "ls"], 0x7fff2bea9258 /* 25 vars */) = 0
brk(NULL) = 0x55e3c31ee000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffef62227b0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=48415, ...}) = 0
mmap(NULL, 48415, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3c1e240000
close(3) = 0
openat(AT_FDCWD, "/lib64/libdevmapper.so.1.02", O_RDONLY|O_CLOEXEC) = 3
. . . . . . . . . . . . . .
mmap(NULL, 337024, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3c1e1dd000
close(3) = 0
uname({sysname="Linux", nodename="master", ...}) = 0
stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(0xa, 0xec), ...}) = 0
openat(AT_FDCWD, "/dev/mapper/control", O_RDWR) = 3
openat(AT_FDCWD, "/proc/devices", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(4, "Character devices:\n 1 mem\n 4 /"..., 1024) = 550
close(4) = 0
По сути, каждый блок вашего виртуального устройства может быть произвольным блоком физического. Главное — правильно описать его в карте, чтобы избежать повторов и т.д.
Карты device-mapper
Мы можем создать файл-описание нашего виртуального устройства со следующим содержимым:
0 100000 linear 8:64 0Это следует читать так: «создаем виртуальное устройство, с нулевого блока этого виртуального устройства используем 100 000 блоков последовательно (линейно) c устройства 8:64 (major:minor) с его начала, без отступа (offset)». Небольшая подсказка про то, какое устройство будет использовано:
# ls -la /dev/sd*
brw-rw---- 1 root disk 8, 0 May 8 13:24 /dev/sda
brw-rw---- 1 root disk 8, 1 May 8 13:24 /dev/sda1
brw-rw---- 1 root disk 8, 2 May 8 13:24 /dev/sda2
brw-rw---- 1 root disk 8, 16 May 8 13:24 /dev/sdb
brw-rw---- 1 root disk 8, 32 May 8 13:24 /dev/sdc
brw-rw---- 1 root disk 8, 48 May 8 13:24 /dev/sdd
brw-rw---- 1 root disk 8, 64 May 18 22:01 /dev/sde
brw-rw---- 1 root disk 8, 80 May 18 22:01 /dev/sdf
echo "0 100000 linear 8:64 0" > /tmp/my-linear-deviceТеперь выполняем команду dmsetup:
[root@oel78 ~]# dmsetup create my-linear-device /tmp/my-linear-deviceПроверяем, появилось ли новое устройство:
#ls -la /dev/mapper/
total 0
drwxr-xr-x 2 root root 120 May 18 22:21 .
drwxr-xr-x 19 root root 3400 May 18 22:21 ..
crw------- 1 root root 10, 236 May 8 13:24 control
lrwxrwxrwx 1 root root 7 May 18 22:21 my-linear-device -> ../dm-2
lrwxrwxrwx 1 root root 7 May 8 13:24 cl-root -> ../dm-0
lrwxrwxrwx 1 root root 7 May 8 13:24 cl-swap -> ../dm-1Помните — ядро позволяет задавать произвольные имена, но делает это как symlink на последовательно создаваемые устройства dm-*.
Теперь с этим устройством можно работать как с обычным диском. Как вы видите, 100 000 блоков на месте:
# fdisk /dev/mapper/my-linear-device
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/mapper/my-linear-device: 51 MB, 51200000 bytes, 100000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x4abaf638
Device Boot Start End Blocks Id System
Command (m for help):Мы также можем сделать файловую систему на нем:
[root@oel78 ~]# mkfs.xfs -f /dev/mapper/my-linear-device
meta-data=/dev/mapper/my-linear-device isize=256 agcount=2, agsize=6250 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0
data = bsize=4096 blocks=12500, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0смонтировать ее:
# mount /dev/mapper/my-linear-device /mntПроверить ее размер:
# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 12G 0 12G 0% /dev
tmpfs 12G 0 12G 0% /dev/shm
tmpfs 12G 42M 12G 1% /run
tmpfs 12G 0 12G 0% /sys/fs/cgroup
/dev/mapper/cl-root 33G 31G 2.0G 94% /
/dev/mapper/my-linear-device 46M 2.6M 43M 6% /mnt
tmpfs 2.4G 44K 2.4G 1% /run/user/0
/dev/sr0 4.6G 4.6G 0 100% /run/media/root/OL-7.9 Server.x86_64
В списке карт device-mapper есть запись и о нашей карте:
# dmsetup table
my-linear-device: 0 100000 linear 8:64 0
cl-swap: 0 2097152 linear 8:2 2048
cl-root: 0 122904576 linear 8:2 2099200
lab-test--vol: 0 4194304 linear 8:112 2048В системе уже есть linear устройства. Они созданы при инсталляции в VG с именем cl, а также во второй VG с именем lab уже руками.
Главное различие карт device-mapper, созданных вручную и через LVM, заключается в том, что созданное вручную живет до первой перезагрузки, а LVMсохраняет свою конфигурацию:
# ls -la /etc/lvm/
total 132
drwxr-xr-x. 6 root root 100 Jun 6 2024 .
drwxr-xr-x. 152 root root 12288 Nov 20 23:17 ..
drwx------. 2 root root 4096 Oct 30 11:47 archive
drwx------. 2 root root 4096 Oct 30 11:47 backup
drwx------. 2 root root 6 Mar 11 2021 cache
-rw-r--r--. 1 root root 103867 Mar 11 2021 lvm.conf
-rw-r--r--. 1 root root 2301 Mar 11 2021 lvmlocal.conf
drwxr-xr-x. 2 root root 245 Jun 6 2024 profile
# ls -la /etc/lvm/backup/
total 56
drwx------. 2 root root 4096 Oct 30 11:47 .
drwxr-xr-x. 6 root root 100 Jun 6 2024 ..
-rw-------. 1 root root 1736 Jun 6 2024 cl
-rw------- 1 root root 1297 Oct 30 11:47 labЗаглянем внутрь файла /etc/lvm/backup/lab:
Скрытый текст
# Generated by LVM2 version 2.03.11(2)-RHEL8 (2021-01-28): Wed Oct 30 11:47:48 2024
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'pvscan --cache --activate ay 8:112'"
creation_host = "master" # Linux master 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Wed Dec 22 13:25:12 UTC 2021 x86_64
creation_time = 1730278068 # Wed Oct 30 11:47:48 2024
lab {
id = "GIYURR-zK0a-WPp2-Grqh-3OTM-Likw-4hvWEO"
seqno = 4
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "twNfpj-oa9b-IscO-WNB0-Bhqu-eCQE-y3R1c6"
device = "/dev/sdh" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 46137344 # 22 Gigabytes
pe_start = 2048
pe_count = 5631 # 21.9961 Gigabytes
}
}
logical_volumes {
test-vol {
id = "CPAXjT-gLOV-yrF6-cR8D-6X3x-6NyT-zNyihQ"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_time = 1730213672 # 2024-10-29 17:54:32 +0300
creation_host = "master"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 512 # 2 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0И теперь для наглядности еще раз конфигурация карты device-mapper:
lab-test--vol: 0 4194304 linear 8:112 2048Легко заметить аналогии, а если заняться математикой, то их станет еще больше, т.к. 2 GiB (2147483648) / 512 = 4194304
# ls -la /dev/sdh
brw-rw---- 1 root disk 8, 112 Nov 20 22:43 /dev/sdhТ.е. LVM просто хранит конфигурацию VG в файле. Но только ли в файле?
LVM умеет передавать VGмежду хостами (export/import). Логично предположить, что конфигурация где-то записывается на диске. Так и есть:
Скрытый текст
# dd if=/dev/sdh of=/tmp/header count=1 bs=1M
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0250576 s, 41.8 MB/s
# strings /tmp/header
LABELONE
LVM2 001twNfpjoa9bIscOWNB0BhqueCQEy3R1c6
e LVM2 x[5A%r0N*>
pt-c
lab {
id = "GIYURR-zK0a-WPp2-Grqh-3OTM-Likw-4hvWEO"
seqno = 1
format = "lvm2"
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "twNfpj-oa9b-IscO-WNB0-Bhqu-eCQE-y3R1c6"
device = "/dev/sdh"
status = ["ALLOCATABLE"]
flags = []
dev_size = 46137344
pe_start = 2048
pe_count = 5631
# Generated by LVM2 version 2.03.11(2)-RHEL8 (2021-01-28): Tue Oct 29 17:53:27 2024
contents = "Text Format Volume Group"
version = 1
description = "Write from vgcreate lab /dev/sdh."
creation_host = "master" # Linux master 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Wed Dec 22 13:25:12 UTC 2021 x86_64
creation_time = 1730213607 # Tue Oct 29 17:53:27 2024
lab {
id = "GIYURR-zK0a-WPp2-Grqh-3OTM-Likw-4hvWEO"
seqno = 2
format = "lvm2"
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "twNfpj-oa9b-IscO-WNB0-Bhqu-eCQE-y3R1c6"
device = "/dev/sdh"
status = ["ALLOCATABLE"]
flags = []
dev_size = 46137344
pe_start = 2048
pe_count = 5631
logical_volumes {
test-vol {
id = "CPAXjT-gLOV-yrF6-cR8D-6X3x-6NyT-zNyihQ"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_time = 1730213672
creation_host = "master"
segment_count = 1
segment1 {
start_extent = 0
extent_count = 512
type = "striped"
stripe_count = 1
stripes = [
"pv0", 0и так далее... Т.е. конфигурация хранится еще и на самом диске.
Типы карт device-mapper
Теперь стоит уделить внимание, какими бывают device-mapper. Сейчас карты бывают:
linear
striped
mirror
snapshot и snapshot-origin
error
zero
multipath
crypt и др.
И если большинство из них интуитивно понятны, то некоторые требуют пояснения. Давайте сначала посмотрим на простую карту, а потом обсудим уже различные типы карт и заглянем за кулисы.
Striped — карта, позволяющая получить stripe-устройство (RAID0).
Mirror — классический RAID1.
snapshot и snapshot-origin — карты, участвующие в создании snapshot какого-либо тома. Например:
# lvcreate -s -L 500M -n test-vol-snap lab/test-vol
Logical volume "test-vol-snap" created.
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root cl -wi-ao---- <58.61g
swap cl -wi-ao---- 1.00g
test-vol lab owi-aos--- 2.00g
test-vol-snap lab swi-a-s--- 500.00m test-vol 0.00 и если опять обратиться к картам, то увидим нечто не очень привычное:
# dmsetup table
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
lab-test--vol: 0 4194304 snapshot-origin 253:4
lab-test--vol--snap-cow: 0 1024000 linear 8:112 4196352
lab-test--vol--snap: 0 4194304 snapshot 253:4 253:5 P 8
lab-test--vol-real: 0 4194304 linear 8:112 2048RedHat в документации объясняет, откуда все это берется:
When you create the first LVM snapshot of a volume, four Device Mapper devices are used:
1. A device with a linear mapping containing the original mapping table of the source volume.
2. A device with a linear mapping used as the copy-on-write (COW) device for the source volume; for each write, the original data is saved in the COW device of each snapshot to keep its visible content unchanged (until the COW device fills up).
3. A device with a snapshot mapping combining #1 and #2, which is the visible snapshot volume
4. The "original" volume (which uses the device number used by the original source volume), whose table is replaced by a "snapshot-origin" mapping from device #1.
Вот почему их четыре. Идем дальше.
Multipath — позволяет создать устройство, доступное по нескольким путям с различными настройками:
# multipath -ll
mpathb (360014057cac55ee036b4bb084f42edf0) dm-2 LIO-ORG,test-vol
size=2.0G features='0' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 34:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=50 status=enabled
`- 33:0:0:0 sdc 8:32 active ready running
# dmsetup table
mpathb: 0 4194304 multipath 0 1 alua 2 1 service-time 0 1 2 8:16 1 1 service-time 0 1 2 8:32 1 1Информацию об остальных типах можно найти здесь, а полный список тут.
Могло ли все быть по-другому?
В Linux существует, как всегда, несколько проектов/решений, и развитие может свернуть на какую-то другую дорогу (привет, SystemD). Так и LVM мог проиграть конкуренцию EVMS, разработанную IBM, но победил.
Вывод
Теперь мы с вами еще немного глубже понимаем работу Linux, что не может нас не радовать. Ну и конечно, плюсик в карму нам обеспечен.
Комментарии (4)
adrozhzhov
29.01.2025 10:42Если мне не изменяет память LVM был в AIX 4й версии и когда IBM стал сильно любить Линукс, добавив к 5й версии букву L он отдал LVM в комьюнити.
Поэтому не проиграть EVMS было не особо сложно.
Кстати, лимит в 16Тыс sdXYZ устройств можно достаточно просто достичь.
Сделать много путей в iscsci до многих портов для полусотни LUN.
После 9 тыс. устройств заметно, как проседает скорость.
JetHabr Автор
29.01.2025 10:42Спасибо за ваше замечание!
История там, на наш взгляд, еще более запутанная. То, что IBM отдал в комьюнити и было EVMS, а то, что потом стало LVM в привычном нам виде, - это синтаксис от HP-UX + код от IBM. Но это было очень давно.
Да, в Enterprise многие лимиты - это не что-то невероятное, а вполне достижимые значения.
outlingo
В общем dm-таргетов намного больше (find /lib/module/$(uname -r) | grep dm-) и некоторые полезны в разработке (dm-dust например), а некоторые в эксплуатации (типа dm-integrity, dm-delay, dm-clone).
JetHabr Автор
Спасибо за уточнение!
Конечно! Очень хотелось "поместиться" в небольшую статью и сильно не выходить за рамки LVM, но породили неточность, что это исчерпывающий сиписок типов карт.