TF
но если у вас это работает, то ок
Size: a a a
2020 July 22
A
Даже больше, можно изменить вверх/вниз потребление. Вниз мы сильно не рекомендуем, но "любой каприз", как говорится...
подобная модель оказания услуг уже в духе "а я винду каждый месяц пересставляю"
A
т.е. расчет если что , только на то что в случае чего накатим заново
NP
Да будет виртосрач! )
I
так же как увеличение разделов на разделе lvm -- плохая практика
ещё плохой практикой считается любое действие или бездействие 😃
i
Да будет виртосрач! )
Я голоден, а наживка выглядит вкусной
A
лучше по VDI подскажите
NP
согласен )) Александр - что-то вы действительно какие-то странные вещи говорите ) особенно про ресайз ext4 и lvm ) но у всех свои бест практис - кто мы такие, чтобы их осуждать?
I
лучше по VDI подскажите
vdi - плохая практика
NS
согласен )) Александр - что-то вы действительно какие-то странные вещи говорите ) особенно про ресайз ext4 и lvm ) но у всех свои бест практис - кто мы такие, чтобы их осуждать?
во-во, у меня скрипт есть для ресайза диска виртуалки(правда только в оффлайне), уже запускали его в проде раз сто наверное. "Ни единого разрыва" (С) Так а тут сразу получается ресайзим lvm-over-lvm и ничего.
A
согласен )) Александр - что-то вы действительно какие-то странные вещи говорите ) особенно про ресайз ext4 и lvm ) но у всех свои бест практис - кто мы такие, чтобы их осуждать?
могу пояснить развернуто, если не очевидно. Когда у вас случится тяжелый сбой и все навернется в труху, то вас сильно выручит если структура раздела будет идентичной той, что получена на блочном устройстве идентичного размера после команды mkfs
A
и много слез будет если оно в неких критичных местах не похожа потому что ее ресайзили или как то еще нестандартно изнасиловали
A
во-во, у меня скрипт есть для ресайза диска виртуалки(правда только в оффлайне), уже запускали его в проде раз сто наверное. "Ни единого разрыва" (С) Так а тут сразу получается ресайзим lvm-over-lvm и ничего.
для ситуаций где не будет больно много раз так делал. Но я никогда не буду так поступать с ответственными данными важного клиента.
A
vdi - плохая практика
дареному коню в зубы не смотрят
NS
для ситуаций где не будет больно много раз так делал. Но я никогда не буду так поступать с ответственными данными важного клиента.
Для важного клиента достаточно не использовать опасных опций, типа async, writeback, ну и рэйд никто не отменял + бэкапы. Если файлуха разлетелась в фарш - то пофиг на лвм она или нет, все равно из бэкапа доставать образ целиком, т.к. на критичных данных изменение даже одного байта недопустимо.
NP
могу пояснить развернуто, если не очевидно. Когда у вас случится тяжелый сбой и все навернется в труху, то вас сильно выручит если структура раздела будет идентичной той, что получена на блочном устройстве идентичного размера после команды mkfs
Ваш подход понятен. Он не очевиден по конечному эффекту, но понятен
NP
т.е. я тоже не очень понимаю зачем ремониторивать fs, которая разлетелась в фарш
A
Nik Sh ну жизнь часто многообразнее. У вас есть например сценарий, что делать если процесс ресайза не завершился успешно а отвалился на середине?
NP
критичные данные должны быть задублированы (БД) или постоянно копируемы (наборы файлов) в любом случае
A
т.е. я тоже не очень понимаю зачем ремониторивать fs, которая разлетелась в фарш
а это часто быстрее , чем поднимать из бекапа