Использование LVM с SSD и SATA дисками


22

В этом вопросе я увидел, что можно поместить как SSD, так и стандартный жесткий диск SATA в одну группу томов LVM (VG).

Как это влияет на производительность?

Есть ли способ заставить ОС находиться на SSD, пока данные находятся на диске SATA в одной группе томов?

Есть ли какие-нибудь хорошие документы по использованию LVM с различными типами дисков?

Было бы полезно создать VG для каждого типа привода и / или скорости? Я думал о создании одного VG для твердотельных накопителей и одного для SATA (и для каждого типа дисков, который я могу добавить в будущем, когда он появится).



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

@Samiam это была моя первая мысль. Я не был уверен, есть ли способы заставить LVM всегда помещать данные, идущие в и из такого-то каталога, в sda и всегда помещать данные, идущие в другой каталог, на sdb.
Ник

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

Ник: Я не могу ответить о LVM с головы до головы, но, да, можно настроить /etc/fstabтак, чтобы /он был на SSD, но все, что ниже /home, на обычном жестком диске. Обычно это вариант при установке любой современной системы Linux ( /homeбудет «точкой монтирования» при выборе какой-либо формы «расширенных параметров»)
samiam

Ответы:


8

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

Кроме того, всегда хорошо монтировать /tmpкаталог на SSD, который обеспечивает огромное ускорение, особенно для приложений, которые используют его, например, для компиляции.


4
Поставь /tmpна tmpfs. Больше производительности, меньше износ SSD (или жесткого диска). Очень быстрое чтение SSD делает его в основном полезным для данных, которые читаются чаще, чем пишутся.
Жиль "ТАК - перестать быть злым"

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


5
Мех. Я обычно хочу, чтобы файлы при /tmpочистке очищались при перезагрузке - если они должны остаться, это то, что нужно /var/tmp. В /tmpтечение многих лет я использовал tmpfs на многих машинах и никогда не приближался к нехватке пространства подкачки, и у меня нет нетипично небольших объемов данных /tmp, так что аргумент является поддельным. В любом случае, это не уязвимость - это слово подразумевает проблему безопасности.
Жиль "ТАК - перестань быть злым"

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

8

В последних версиях LVM вы можете создать один «исходный» LV на жестком диске и один «кэш-пул» LV на SSD, а затем объединить его в один «кэш» LV. Он имеет тот же размер, что и «исходный» LV (т. Е. Вы получаете столько же места, сколько на жестком диске), но часто используемые блоки и метаданные кэшируются на SSD для повышения производительности.

Суть в том, что если у вас уже есть VG, охватывающий оба диска:

lvcreate -l 100%PVS -n your_name YourVG /dev/YourHDD
lvcreate --type cache-pool -l 100%PVS -n your_name_cache YourVG /dev/YourSSD
lvconvert --type cache --cachepool YourVG/your_name_cache YourVG/your_name

После этого у вас будет your_nameLV, который вы можете использовать, как и любой другой LV, и несколько внутренних LV, которые вы сможете увидеть lvs -a YourVG.

Например, я настроил зашифрованную корневую файловую систему через раздел SSD ( /dev/sda3) и раздел HDD ( /dev/sdb1) с помощью следующих команд:

pvcreate /dev/sda3 /dev/sdb1
vgcreate RootVG /dev/sda3 /dev/sdb1
lvcreate -l 100%PVS -n cryptroot RootVG /dev/sdb1
lvcreate --type cache-pool -l 100%PVS -n cryptroot_cache RootVG /dev/sda3
lvconvert --type cache --cachepool RootVG/cryptroot_cache RootVG/cryptroot
cryptsetup luksFormat --type luks2 /dev/RootVG/cryptroot

Вы можете найти более подробную информацию в этом блоге или в этом . (Первый - то, что я использовал для справки, а также в качестве ссылки на статью в Википедии LVM; второй - я, описывающий, как я использовал его на практике. Решите для себя, какой из них вы хотите доверять 😉)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.