Раздел swap - на LVM или нет?
 

Привет!

Кто как делает своп-раздел при разметке диска?
Есть ли какие-то аргументы против создания этого раздела как LVM LV?

Когда делаешь LVM, то нет смысла что-либо (кроме /boot) выносить за LVM.
Никаких аргументов против я не знаю. Одни только плюсы - возможность переноса, возможность расширения, возможность шифрования тем же LUKS.

А да, оставляйте на PV процентов 5-10% диска свободными для манёвров. Ну и SSD это тоже полезно.

DJ Mogarych, делайте swap файлом - это гораздо гибче, чем HDD нашинкованный на кучу pv собранных потом обратно в пару lv

Я так делаю, когда нет доступа к железу, например на VPS. Там это оправдано, потому что другого способа-то и нет :)
Это кто ж так делает? Одно блочное устройство – один PV. Буква "P" как бы намекает. Можно конечно нашинковать диск на разделы и из них сделать кучу PV, но в упор не вижу, зачем. Где вы такие чудеса видели-то?

Рецепты для какой проблемы? Оки, предложу самую распространённую проблему и её решение - на группе томов место кончается, что делаем - докидываем физические диски (массивы, не суть, блочные устройства), делаем на них pvcreate, потом vgextend на них, потом lvextend. Вуаля - проблема решена даж без простоя.
Или другая - подыхает блочное устройство, смарт кричит. Оки, подкидываем другое устройство, делаем pvcreate и помолясь pvmove. Если боги нас любят, то опять всё колосится без простоя.

Нужно ж знать что для чего, а не тупо копипастить примеры.

Jula0071, а в чём минусы файла по отношению к разделу, если есть возможность делать и то, и другое?

Вопрос звучит с интонацией, почему нельзя делать так, если можно делать этак. В данном контексте, можно делать как считаешь нужным, по обстоятельствам.

Критических минусов нет. Разве что, лишний оверхед фс и её журнала, который свапу не нужен совсем, там страничный доступ. Ну и если фс откинется, то с ней и свап, впрочем его проблемы уже вряд ли будут интересны. Хотя иногда лучше получить полуживой сервер с фс, ушедшей в ro, чем kernel panic.

Вообще свап сегодня нужен для двух вещей – чтоб не приходила расстрельная команда oom-killer, и на десктопе – для спящего режима. Если у вопроса корни растут от нехватки памяти, то не надо растить свап, надо растить память, или оптимизировать софт, урезая его аппетиты.

Нет, тут без интонации, просто хочется прояснить вопрос.

Давно уже не делаю swap. С нынешними объёмами RAM это архаизм.

А что произойдёт, если память кончится, а свопа нету?
"Нынешние объёмы РАМ", к сожалению, есть не у всех.

Вот люди тоже задаются тем же вопросом, что и я:
https://askubuntu.com/questions/1059...tition-or-file
https://askubuntu.com/questions/9043...n-vs-swap-file
Оказывается, в Убунте, начиная с версии 17.04, используется своп-файл вместо раздела. Это объясняется тем, что фрагментация как негативное влияние на файл сейчас становится неактуальной, а ещё - что своп плохо влияет на продолжительность жизни SSD.

Придёт OOM-killer и пристрелит процесс, который сочтёт "плохим". "Плохость" вычисляется по специальному алгоритму. "Плохим" может оказаться и что-то важное, чем не хотелось бы жертвовать, например СУБД. Статья.
Как будто своп на фс влияет хорошо. :)
Вообще там говорят, что главный резон это лёгкость расширения свопа, в случае если просчитался с его размером. Ну... пожалуй, хотя с LVM это тоже не сложно, хотя конечно нужно больше телодвижений. Хотя моё мнение по поводу наращивания свапа я уже высказывал, нужно не растить свап, а решать проблему иначе. Также никто не запрещает не расширять имеющийся, а добавлять новый свап.

Всем спасибо, пожалуй, я остановлюсь на файле, а не на разделе, тем более что, убунта и вправду создаёт /swapfile в ходе установки.
В принципе, действительно, если уже своп используется всерьёз на серверной системе, то тут надо срочно что-то решать, ибо долго так всё равно продолжаться не может.

Если уже есть как есть - с файлом, то заморачиваться переделкой точно не стоит. А вот если ставить что-то новое с нуля, то можно и сделать покрасивее. Но опять же, если эта красота никому не нужна, то и заморачиваться нечего.

Ну а как покрасивее? Раздел на LVM?

DJ Mogarych, красота понятие отвлечённое. Нужно соотносить затраченные усилия, риски и результат. LVM полезен, доводы приводил (кстати забыл ещё один - возможность делать снапшоты томов, например для консистентного бекапа) но его надо знать и уметь готовить (как и практически всё в линуксе - свобода настроек огромная, но никто не гарантирует, что не будет выстрела в ногу). Если не знаете, то в проде лучше ничего не трогать. Не надо чинить то, что не сломано. Изучайте LVM, тренируйтесь на тестовых вмках, если зайдёт, будете сами в какой-то момент удивляться "как я жил без LVM". Но в проде, чувствую, вам рановато (просто не возник бы обсуждаемый вопрос). А не зайдёт, так и бог с ним.

У меня на самых толстых хостах по терабайту RAM, но и там иногда OOM приходит. Там контейнеры вестимо, приходит не из-за того, что физическая память кончилась, а по ограничению контейнера. Случится пик и опа. Раздавать всем память не глядя всё ж расточительно, так что для страховки свап. Если он растёт перманентно, тогда и докинуть памяти.
Ещё есть виртуалки в разных облаках, а там обычно добавить память не так просто, нужно переходить на другой план, который вдвое дороже (например 8ГБ в ДО стоит 20 баксов/мес, а следующий - 16 и уже 40). Из-за редких пиков опять же расточительно, потому свап.

Так что не надо свап со счетов списывать, он полезный. Кушать не особо много просит, 1-8ГБ стореджа для страховки как правило приемлемо. А если хочется чтоб меньше свапилось, можно прикрутить гайку vm.swappinness с умолчальных 60 до 10-20.

Я давно уже ставлю LVM в прод, просто авторазметкой. Тут, наконец, захотелось разобраться самому.

Насколько я помню авторазметку той же убунты, там не оставляли резервное свободное место на PV.

Это да, поэтому я и заинтересовался темой, чтобы размечать диски лучше и правильней.

В принципе логические тома можно и укорачивать. Но то, в отличие от расширения, опасная процедура, если на лету. Надо umount, что не всегда возможно, например с рутом.