Лвм говно посоны

С ним онлайн-ресайз работает, что удобно

Как на увеличение, так и на сокращение

сломался то не лвм, а фс внутри него

Пропустил немного, суперблоки живые?

Я бы через Sleuth Kit прогнал фс, если просто dd блочного устройства не помогает. Был ещё дистрибутив CAINE, но с ним сложнее

Всем добрый. Есть вопрос по lvm. Кто-нибудь делал так:

# for n in {b,c,d,e}; do sgdisk -N 1 /dev/sd$n; done
# pvcreate /dev/sd{b1,c1,d1,e1}
# vgcreate r10 /dev/sd{b1,c1,d1,e1}
# lvcreate --type raid10 --mirrors 1 --stripes 2 -l 70%FREE --name r10_thinpool r10 /dev/sd{b1,c1,d1,e1}
# lvcreate --type raid10 --mirrors 1 --stripes 2 -l 50%FREE --name r10_thinmeta r10 /dev/sd{b1,c1,d1,e1}
# lvconvert --thinpool r10/r10_thinpool --poolmetadata r10/r10_thinmeta

В итоге получаем raid 10 тонкий том, где сам рейд собирает lvm обращаясь к md прослойке без mdadm.

Хочу такую штуку использовать для проксмокс кластера, в связке с DRBD9

Технически я оттестил это решение, все работает норм, но вот я никак не могу решить проблему с восстановлением thin lvm массива типа raid 10, по каким только инструкциям не делал - ничего не получается.

Если вынуть из массива диск, а вставить новый, то никак без потери массива или данных он не собирается.

скурил man thinlvm за ним man lvmraid, а затем еще и gentoo wiki + rhel lvm guide и не пойму, вот собрав по командам выше массив, вынув из него диск, как подключить новый и на горячую ребилднуть массив?

На вопрос зачем - вводная, 3 сервера по 2 зеона(8 ядер 16 потоков), 12 дисков по 8ТБ, 4 ссд по 800ГБ, и 64ГБ памяти. Исходя из условий ceph, а за ним zfs+что-то(glusterfs/drbd9 ...) отпадают из-за конских требований по памяти для обслуживания такого RAW пространства. Остается thinlvm+drbd9, как drbd9 по памяти я не знаю, подозреваю лучше чем zfs или ceph, а вот то что thinlvm по скорости одно из самых быстрых решений, а по памяти можно вообще не заморачиваться, это да.

потому, стоит кому-то переехать из proxmox, я верно понял намек?

Zfs'у сколько памяти дадите - столько и заюзает под кеш, смотрите https://github.com/zfsonlinux/zfs/wiki/ZFS-on-Linux-Module-Parameters#zfs_arc_max

1. Чем вам не угодил mdraid, что решили от него прям отказаться? На lvm много ругани было помню и много функций связанных с восстановлением отсутствовало.
2. Выбор тонких томов обусловлен чем? Если будете много клонировать/снапшотить - тогда понятно, если не будете то зачем? оно тормознее чем raw.
3. Когда я выбирал cow под определенные задачи, то у нас на всех тестах лучше всего себя показал mdraid + vdo (правда на ssd-дисках), память тоже жрет, но тонко настраивается в одном конфиге, чем больше памяти - тем лучше работает.

Это я знаю, но остается вопрос производительности, ну урежу я его гиг до 64. А везде требуют 1 гиг памяти на 1ТБ чистого дискового пространства. Каковы потери производительности zfs в таком режиме. Ну и придется 2 ссд отдать под zil, а не хотелось бы.

Зачем лишняя прослойка, ну и рпзрабы рекоммендуют не делать mdadm а сразу юзать lvmraid. Да планируются снапшоты. Выбор обусловлен минимальными затратами на память и по тестам фактически самой высокой производительностью, быстрее только lvm чистый.

Кто где требует гиг на тб?) миф, как и на любой другой фс - сколько отдадите под кеш - на столько хорошо и будет. Если что в этот гиг не поместилось - значит это менее актуально было.  Главное дедуп не включайте - там да, т.к. дедупликация онлайн, сейчас нужно около 320байт озу на каждый recordsize блок, не поместится в озу вся ddt - привет дикая просадка.

но стоит всё тестить, да, zfs не панацея

mdraid и zfs хоть работает, а lvmthin у меня развалился 1раз, когда данных стало больше чем места. причем как я понял прокс не контроллит этот момент