Как сжать том линукс

Как работать с LVM

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

Используемые команды одинаково подойдут как для систем Red Hat / CentOS, так и Debian / Ubuntu.

Уровни абстракции

Работа с томами с помощью LVM происходит на 3-х уровнях абстракции:

  1. Физический уровень (PV). Сначала диск инициализируется командой pvcreate — в начале диска создается дескриптор группы томов. При этом важно заметить, что диск не обязательно должен быть физическим — мы можно отметить на использование обычный раздел диска.
  2. Группа томов (VG). С помощью команды vgcreate создается группа томов из инициализированных на предыдущем этапе дисков.
  3. Логический том (LV). Группы томов нарезаются на логические тома командой lvcreate.

Схематично, уровни можно представить так:

Установка

Для работы с LVM необходима установка одноименной утилиты. В системе Linux она может быть установлена по умолчанию. Но если ее нет, выполняем инструкцию ниже.

Если используем системы на безе deb (Ubuntu, Debian, Mint):

apt-get install lvm2

Если используем системы на безе RPM (Red Hat, CentOS, Fedora):

yum install lvm2

Создание разделов

Рассмотрим пример создания томов из дисков sdb и sdc с помощью LVM.

1. Инициализация

Помечаем диски, что они будут использоваться для LVM:

pvcreate /dev/sdb /dev/sdc

* напомним, что в качестве примера нами используются диски sdb и sdc.

Посмотреть, что диск может использоваться LMV можно командой:

В нашем случае мы должны увидеть что-то на подобие:

«/dev/sdb» is a new physical volume of «1,00 GiB»
— NEW Physical volume —
PV Name /dev/sdb
VG Name
PV Size 1,00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID rR8qya-eJes-7AC5-wuxv-CT7a-o30m-bnUrWa

«/dev/sdc» is a new physical volume of «1,00 GiB»
— NEW Physical volume —
PV Name /dev/sdc
VG Name
PV Size 1,00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID 2jIgFd-gQvH-cYkf-9K7N-M7cB-WWGE-9dzHIY

  • PV Name — имя диска.
  • VG Name — группа томов, в которую входит данный диск (в нашем случае пусто, так как мы еще не добавили его в группу).
  • PV Size — размер диска.
  • Allocatable — распределение по группам. Если NO, то диск еще не задействован и его необходимо для использования включить в группу.
  • PE Size — размер физического фрагмента (экстента). Пока диск не добавлен в группу, значение будет 0.
  • Total PE — количество физических экстентов.
  • Free PE — количество свободных физических экстентов.
  • Allocated PE — распределенные экстенты.
  • PV UUID — идентификатор физического раздела.

2. Создание групп томов

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

Группа может быть создана:

vgcreate vg01 /dev/sdb /dev/sdc

* где vg01 — произвольное имя создаваемой группы; /dev/sdb, /dev/sdc — наши диски.

Просмотреть информацию о созданных группах можно командой:

На что мы получим, примерно, следующее:

— Volume group —
VG Name vg01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 1,99 GiB
PE Size 4,00 MiB
Total PE 510
Alloc PE / Size 0 / 0
Free PE / Size 510 / 1,99 GiB
VG UUID b0FAUz-wlXt-Hzqz-Sxs4-oEgZ-aquZ-jLzfKz

  • VG Name — имя группы.
  • Format — версия подсистемы, используемая для создания группы.
  • Metadata Areas — область размещения метаданных. Увеличивается на единицу с созданием каждой группы.
  • VG Access — уровень доступа к группе томов.
  • VG Size — суммарный объем всех дисков, которые входят в группу.
  • PE Size — размер физического фрагмента (экстента).
  • Total PE — количество физических экстентов.
  • Alloc PE / Size — распределенное пространство: колическтво экстентов / объем.
  • Free PE / Size — свободное пространство: колическтво экстентов / объем.
  • VG UUID — идентификатор группы.

3. Создание логических томов

Последний этап — создание логического раздела их группы томов командой lvcreate. Ее синтаксис:

Примеры создания логических томов:

lvcreate -L 1G vg01

* создание тома на 1 Гб из группы vg01.

lvcreate -L50 -n lv01 vg01

* создание тома с именем lv01 на 50 Мб из группы vg01.

lvcreate -l 40%VG vg01

* при создании тома используется 40% от дискового пространства группы vg01.

lvcreate -l 100%FREE -n lv01 vg01

* использовать все свободное пространство группы vg01 при создании логического тома.
* также можно использовать %PVS — процент места от физического тома (PV); %ORIGIN — размер оригинального тома (применяется для снапшотов).

Посмотрим информацию о созданном томе:

— Logical volume —
LV Path /dev/vg01/lv01
LV Name lv01
VG Name vg01
LV UUID 4nQ2rp-7AcZ-ePEQ-AdUr-qcR7-i4rq-vDISfD
LV Write Access read/write
LV Creation host, time vln.dmosk.local, 2019-03-18 20:01:14 +0300
LV Status available
# open 0
LV Size 52,00 MiB
Current LE 13
Segments 1
Allocation inherit
Read ahead sectors auto
— currently set to 8192
Block device 253:2

  • LV Path — путь к устройству логического тома.
  • LV Name — имя логического тома.
  • VG Name — имя группы томов.
  • LV UUID — идентификатор.
  • LV Write Access — уровень доступа.
  • LV Creation host, time — имя компьютера и дата, когда был создан том.
  • LV Size — объем дискового пространства, доступный для использования.
  • Current LE — количество логических экстентов.

Создание файловой системы и монтирование тома

Чтобы начать использовать созданный том, необходимо его отформатировать, создав файловую систему и примонтировать раздел в каталог.

Файловая система

Процесс создания файловой системы на томах LVM ничем не отличается от работы с любыми другими разделами.

Например, для создания файловой системы ext4 вводим:

* vg01 — наша группа томов; lv01 — логический том.

Для создания, например, файловой системы xfs вводим:

Монтирование

Как и в случае с файловой системой, процесс монтирования не сильно отличается от разделов, созданных другими методами.

Для разового монтирования пользуемся командой:

mount /dev/vg01/lv01 /mnt

* где /dev/vg01/lv01 — созданный нами логический том, /mnt — раздел, в который мы хотим примонтировать раздел.

Для постоянного монтирования раздела добавляем строку в fstab:

/dev/vg01/lv01 /mnt ext4 defaults 1 2

* в данном примере мы монтируем при загрузке системы том /dev/vg01/lv01 в каталог /mnt; используется файловая система ext4.

Проверяем настройку fstab, смонтировав раздел:

Проверяем, что диск примонтирован:

Просмотр информации

Разберемся, как получить информацию о дисковых накопителях в системе.

1. Для общего представления дисков, разделов и томов вводим:

Мы получим что-то на подобие:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
sda1 8:1 0 1G 0 part /boot
sda2 8:2 0 29G 0 part
sys-root 253:0 0 27G 0 lvm /
sys-swap 253:1 0 2G 0 lvm [SWAP]
sdb 8:16 0 1G 0 disk
vg01-lv01-real 253:3 0 1G 0 lvm
vg01-lv01 253:2 0 1G 0 lvm /mnt
vg01-sn01 253:5 0 1G 0 lvm
sdc 8:32 0 1G 0 disk
vg01-lv01-real 253:3 0 1G 0 lvm
vg01-lv01 253:2 0 1G 0 lvm /mnt
vg01-sn01 253:5 0 1G 0 lvm
vg01-sn01-cow 253:4 0 500M 0 lvm
vg01-sn01 253:5 0 1G 0 lvm
sdd 8:48 0 1G 0 disk

* как видим, команда отображает корневое блочное устройство, какие разделы из него сделаны и в какие логические тома организованы из некоторых из разделов.

2. Получить информацию о проинициализированных для LVM дисков:

Источник

Как сжать раздел в Linux (как в винде на диске хранятся сжатые файлы) (Linux Mint (Ubuntu))

Как сжать раздел в Linux (как в винде на диске хранятся сжатые файлы)(к примеру на раздел размером в 100 гигов можно запихать

180)? (Linux Mint (Ubuntu))

two cups for this man
любой вопрос о файловых системах нужно скатывать к ZFS
zfs create -o compression=lz4 -o exec=off -o setuid=off rpool/mystore

Форматируешь раздел в zfs и выбираешь с 5 по 7 уровень компрессии.
Меньше будет не дожимать, больше заметного профита без относительно к затрачиваемым ресурсам.

может лучше zlib, алгоритм старый и окатаный, глюков не будет.
И 4 будет не дожимать, надо ставить 6

творчески переработал выхлоп zpool history
использую ZFS но не ZoL, выбор лишь из опций compression=on | off | lzjb | gzip | gzip-N | zle | lz4

Ну почему обязательно zfs? Можно и Raiser4, например ;).

моё мнение не относится к теме треда, всё же, zfs один из лучших примеров работы инженеров.
не идеальный пример, есть свои минусы, но среди остальных fs или lvm конкурентов не вижу.

всё же, zfs один из лучших примеров работы инженеров.

Согласен :). Упомянул Reiser4 для объективности, чтобы создать у автора темы иллюзию выбора ;).

Я имел ввиду gzip-6, забыл как еравильно, так как давно не пользовался.

К стати, а мелкие файлы которые долго не читали zfs больше не теряет?

gzip немного лучше сжимает, но накладные расходы на процессор делают его очень медленным, в некоторых тестах, в 6 раз медленнее lz4
если есть терабайты хорошо сжимаемых данных, вроде текста и не критична скорость чтения\записи наверное можно использовать gzip.
lz4 требует немного больше памяти, сжимает примерно на 50% хуже чем gzip-9, но с ним скорость выше, чем вообще без сжатия.

К стати, а мелкие файлы которые долго не читали zfs больше не теряет?

ничего об этом не знаю

мелкие файлы которые долго не читали zfs больше не теряет?

General — не место для городских легенд, мифов и прочих баек.

Из линуксовых ФС прозрачное сжатие поддерживает только Btrfs, включается оно опцией монтирования compress=lzo или compress=zlib. Первое сжимает хуже, но работает быстрее, это подойдёт для корня или /home. Второе жмёт лучше, но медленнее, это подойдёт для файлопомойки.

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

Со всеми ними есть сложности, сначала стоит проверить на некритичных данных.

Более надежный вариат — squashfs. Чтение прозрачное, но создается\дозаписывается как архив.

среди остальных fs или lvm конкурентов не вижу.

Верно, особенно если забыть о ресурсоемкости, низком быстродействии, которое пытаются компенсировать большой памятью, фрагментации из-за COW, требования к RAM чтобы ECC, требования к дискам чтобы не домашнее говно, кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), .

А так то да замечательный комбайн!

но и в них практически нельзя переключать сжатие отдельных файлов

В btrfs можно. Чуть менее удобно, чем в винде, но по смыслу идентично.

General — не место для городских легенд, мифов и прочих баек.

пять 4.2 из шести, если прочесть «требования к ECC» как «рекомендация». иначе, все шесть из шести.

Поищи на ЛОРе, как только есть проблема с ZFS, то местные сектанты сразу: «У тебя же память без ECC, у тебя диски не ынтерпрайзные» и т.д. и т.п.

А так-то да отличный комбайн!

послушай, если бы это была какая то очень редкая технология или продукт, вроде эльбруса — я бы понял почему у тебя такая реакция и вера в мифы. даже накидал ссылок по каждому пункту.
но, дружище, весь интернет переполнен статьями. теоретическими, практическими, где на разном уровне доступности объясняются\опровергаются эти мифы.
даже, внезапно, не относящиеся к ZFS: у тебя диски не ынтерпрайзные

У меня архив порнушки накрылся известным органом, причем, что самое символичное, на FreeBSD (FreeNAS)

Не, я конечно понимаю, что 160-гиговый ide диск это не Ъ, но все же.

Ой, у тебя припекает?

Энтерпрайзные диски не то и энтерпрайзные, что если что сломалось, не тормозят по секунде на сектор, пытаясь скорректировать данные с помощью ECC, а сразу без тормозов выдают «Полимеры про..люблены»

ИЧСХ, для той-же ZFS этот вариант лучше.

Никто не говорит, что другие ФС не получат плюшек от ECC RAM.

Только вот из-за сложности структуры, ZFS (как и reiser4, внезапно) имеет куда большую площадь поражения. Соответственно инцидентов было больше.

Samba + Qemu + Windows 10 + NTFS. Получаешь выборочное сжатие файлов и папок. Стабильность и Enterpise.

Не желание принимать действительность это уже диагноз.

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

Миф? Да миф, но только до первых проблем, потом не миф.

требования к дискам чтобы не домашнее говно

Миф? Да миф, но только до первых проблем, потом не миф.

кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), .

Миф? Миф, но только до первых проблем, потом тебе тыкают в пятитомник «как настроить ZFS за 21 день»

Ой, у тебя припекает?
имеет куда большую площадь поражения
инцидентов было больше

мне абсолютно очевидно, что пытаться завязать дискуссию таким образом — это путь в никуда.
начиная с недопонимания моего лексикона, из за чего, ты некоторые обороты речи считаешь моей эмоциональной реакцией.
заканчивая очередными пространными утверждениями о сложности структуры, площади поражения и большем количестве инцидентов.
последнее вообще, читать можно только отдельными фразами, если прочесть как предложения — теряется вообще любая смысловая нагрузка.
будь так добр, объясни последние два предложения общепринятыми хоть где-то в IT терминами.

я возражаю по всем пунктам. прошу занести в протокол, последний пункт вызывает у подзащитного особо резкое порицание, как ценителя красивых UI\UX решений.

Всё так, но фанбоям хоть в глаза писай

Это не миф, а реально пропавщие картинки с сохранёных вебстраниц и сообщения при скрубе о том, что в таких то файлах ошибка.

Это не миф, а реально пропавщие картинки

Выяснили же пару-тройку недель назад, что у тебя железо неисправно. Ты сам признался, что у тебя все ФС, кроме btrfs, крашатся и теряют файлы.
ZFS не теряет файлы, от слова совсем. У меня есть сторадж на одном проекте, примечателен тем, что там десятки миллионов мелких файлов, которые копятся с 2013 года, все живы.

кол-во опций настроек больше чем у всего ядра (высокий порог вхождения), .

Но они логично организованы по задачам, по этому этот пункт имхо не правилен, по крайней мере года четыре назад талмуд читать было удобно.

Это были флешки, а не вестерны в райдовой редакции и вообще другой компьютер.

Во вторых ext4 теряли файлы после выключения ПК, в некоторых случаях после перезагрузки, и то только в том случае, если я не отмонтировал раздел в ручную выполнив тройной синк до и после отмонтирования раздела.
Так что не рассказывай мне, zfs теряла ДАВНО удачно сохранённые файлы и на приличных дисках с райдконтролёром(я для полного фарша даже мнтеловские карзины купил).

Самый эпичный пример это когда фс фейлиться сразу после установки чистой системы, с тех пор прежде чем завершить установку отмонтировываю /target руками.

Считаешь что /sys организован не логично?

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

Так что не рассказывай мне, zfs теряла ДАВНО удачно сохранённые файлы и на приличных дисках

Что говорил scrub?

Точно не помню, про ошибки чексум.

Битое железо. Если ошибки чексум были на всех дисках массива, то это 100% битая память.

Диски были НОВЫЕ Western Digital Raid Edition, в 5 рейде с включёнными чексуммами блоков.
1) Как могло получиться что блок одновременно повреждался на двух разных дисках?
2) Почему аппаратные агрехи не сказывались на крупных файлах, а только на мелочи и не менее как пол года лежания?
Недавно сохранённые страницы открывались нормально.

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

Почему аппаратные агрехи не сказывались на крупных файлах, а только на мелочи и не менее как пол года лежания?

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

В общем нормальных объяснений у тебя нету.

Я объяснил предельно понятно. Если это объяснение лично тебе не нравится, это не значит что оно неправильное.

Э, ну ты же сказал что настройки zfs организованы лучше, а это сравнение с чем-то (ядром). Так с чем ты сравнивал и получил в результате «лучше»?

вместо того чтобы спорить, лучше бы обнародовал ядро, версию и свои суперудачные настройки zfs

там десятки миллионов мелких файлов, которые копятся с 2013 года, все живы.

Если бы дело было в оборудовании то глючила бы вся ФС в целом, а не какая то малая, нечто вроде 1МБ/2ТБ её часть, а глюки бы корелировали не с размером файла, а с кажем с объёмом записи или чтения с диска в момент их записи.

Ну не так логично как ман к btrfs или zfs.
Во всяком случае в последних проще разобраться.

Ядро разное, как и версия zol. Начинался проект на ubuntu server 12.04,сейчас на 14.04. Zol сначала был 0.6.1, сейчас 0.6.5.11

Только вот из-за сложности структуры, ZFS (как и reiser4, внезапно) имеет куда большую площадь поражения.

Что за такая «площадь поражения»? В каких единицах она измеряется?

inotify + любое сжатие, и плевать на фс (выше отписавшиеся хомячки)

предугадывая вопли о своей якобы компетентности смею заметить, что с помощью inotify можно хоть по MIME типу указать каким алгоритмом сжимать, и сжимать ли вообще, на что никакая фс ещё не способна

inotify + любое сжатие, и плевать на фс

Ну, тогда ФС наплюёт на твоё сжатие. Отведёт под сжатый 4К-файл целый блок. Сжимай, не сжимай — на диске занято столько же — 4К.

Источник

Mac OS X Hints
Adblock
detector