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

Да ну ... начиная с ядра там капец. Сравнивая ядро фрибзди и линуха можно афигеть ...

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

Вообще тебе бы сразу Linstor взять с таким кейсом

У тебя же --mirrors 1 --stripes 4 Ты вообще уверен, что оно должно быть отказоустойчиво с 4мя страйпами на 4х дисках?

У тебя же --mirrors 1 --stripes 4 Ты вообще уверен, что оно должно быть отказоустойчиво с 4мя страйпами на 4х дисках?

там вроде через сеть не нужно было, или я пропустил в требованиях?

Ну он всё равно хотел DRBD поверх thinlvm, так вот Linstor это и делает, просто автоматически

Ну он всё равно хотел DRBD поверх thinlvm, так вот Linstor это и делает, просто автоматически

Так я это и хочу. DRBD 9 имеет плагин для прокса, а работает поверх thinlvm или zfs. Вот я и хочу thinlvm пулы, поверх linstor + drbd9 и все через плагин скормить проксу.

Не совсем понятно зачем тебе mirror на стороне lvm

Если локально сдохнет диск что бы локальный сторадж работал до замены. Или есть предложение запилить тонкий пул и реплицировать через линстор и дрбд, а если сдохнет то виртуалки уедут на другую ноду?

Да но тогда трафик виртуалок будет гонятся до второй ноды через сеть.