Comments 74
Хороший материал.
Как интересно как с поддержкой всего этого дело под виндами?
Вроде максимум что можно добиться — чтение с таких разделов.
А я хотел при помощи такой штуки объеденить три своих харда поставить порой винду и линух, жаль. отя как время подойдет переставлять все, я еще раз почиаю.
Возьмите LVM, насоздавайте разделов и скормите их винде, установленной под XEN.
под win есть «динамические диски» — как мне показалось, практически то же самое… только мышкой и не так понятно :)
Динамические диски. Только аккуратней с ними — если что-нибудь случится с одним из винтов, ни одна утилита Вам не поможет восстановить данные со всех(!) дисков. (Если я не ошибаюсь :)
Есть unionfs — позволяет объединять логические разделы в один большой, с последовательным заполнением.
Т.е. есть 2 диска по 100 Gb — объединяем — первые 100 Gb пишутся на первый диск, следующие — на второй.
Прогиб по скорости, НО — если что-то умрет — оно умрет только со своим куском данных.
Погуглите.
Хотите сказать unionfs работает в windows?
P.S. Я не пользуюсь windows, просто интересно, если это действительно так. :)
? Я???
Нет, я мало того что не хочу этого говорить, так еще и не скажу!
Unionfs работает только в *BSD и Linux, ну может еще куда-то спортировали.
какой-такой виндувс…
Спасибо, уважаемый!
Давно хотел изучить эту тему, а тут Вы. Как раз во время и очень доходчиво. Вам +, а материал в закладки.
О как раз пришлось перепродать часть серва, собрал остатки свободного места воедино при помощи LVM и получил 100гб =)
«Поздравляю, Шарик, ты балбес!» ©

Страйп-массив на сервере — это что-то!
Потому что страйп-массив — это логический эквивалент «обрал остатки свободного места воедино».
UFO landed and left these words here
Вот кстати, а как с производительностью у LVM? Интересует личный опыт.

Вроде, кстати, LVM умеет шифровать. Так вот, а при включённом шифровании какова производительность?
По поводу производительности, отличий «на глаз» не заметил. По моим тестам тоже всё в районе погрешностей.
С шифрованием у меня как-то не срослось, я его попробовал и понял что мне оно не надо — у меня практически нет никакой ценной инфы на локальных машинах…
LVM не умеет шифровать. Но для шифрования диска используется вот по какой причине. Для линукса нужно хотя бы 2 раздела: / и swap. Так вот, если шифровать 2 раздела по отдельности, то придётся два раза вводить пароль при загрузке. Можно конечно при каждой загрузке перешифровывать /swap заново сгенерированным ключом, но тогда suspend не получится использовать.

Так что обычно создают LVM, его шифруют и в получившемся зашифрованном устройстве создают уже / и /swap.

Таким образом, пароль при запуске вводится один раз, а зашифрованных разделов может быть несколько.

ыы производительность норм, шифровать lvm не умеет сам, я шифровал разделы отдельно, потом поверх них идет lvm
собственно да, для шифрования используется luks (по крайней мере в моём случае).
А 6 HDD тут при чем? Давно уже по меткам модно монтировать, бубунта по дефолту так и делает.
Да там и по меткам пробовали — не плучается. Винчестеры стартуют вразнобой, система им отдаёт разные устройства /dev. Цитата: "(монтирование по UUID почему-то вообще не срабатывает — будто бы идентификаторы одинаковые)".
6hdd не актуально, ибо lvm основывается на uuid'ах устройств и метадате, потому абсолютно не важно как будут называться блочные устройства.
Кстати, про восстановление — там винт сломался, если кусочек ФС на винте лежит без дублирование то восстановление вне зависимости от LVM будет тем еще счастьем.
UFO landed and left these words here
Не знаю мне гораздо проще скопировать систему на новый винт с livecd (cp -a на много более юзабельное шаманство ;)). Так и не понял в чем «безопасность» и в чем прикол такой организации на десктопе. в прочем «кто как хочет — так и дрочит» (с) из к/ф «Брат»
Под «безопасностью» я имел ввиду вынос /tmp и /home на отдельный раздел из корня, чтобы не получилось так что машина не грузится потому, что диск переполнен.
Можно ли с ним сделать такое:
Создать раздел на 16 гиг, чтобы на нем работала и жила система, и реплицировать этот раздел на флешку 16 гиг, чтобы можно было вытащить его и получить копию минутной например давности?
можно с помощью снапшотов.., обычно это делается так:

# lvcreate -s -n snap_home -L2G /dev/ws/home # в той же группе томов создаётся снапшот нужного раздела.

# mount /dev/ws/snap_home /mnt/snapshots # полученый раздел прицепляется в папку,

# tar -cvzf home.tgz /mnt/snapshots # с него забирается инфа (например можно всё сразу залить в архив).

# umount /dev/ws/snap_home # отцепляем раздел

# lvremove /dev/ws/snap_home # удаляем за ненадобностью.

А реплицировать «на лету» оно не может, чтобы не делать долгое копирование? Зеркалирование не поможет?
Честно говоря не совсем понимаю, что имеется в виду под «реплицировать «на лету»» и получить копию минутной например давности.
Если нужен «снимок» в конкретный момент времени — делаем снапшот, если 2 обновляемые в реальном времени копии fs — зеркалирование… можно делать и то и другое при желании.
Средствами lvm можно делать, как snapshots, так и зеркалирование отдельных lv.
Это всё, конечно, хорошо. Ровно до тех пор, как у вас один из дисков накроется :) Потом будет очень много танцев с бубнами вокруг того, чтобы восстановить данные.
опыт показывает что, если нет мониторинга винтов и устойчивого к сбоям рэида или зеркалирования (можно даже lvm'ом) — танцы с бубном чтобы восстановить данные будут в любом случае. ;)
Ну. Там будут танцы вокруг повреждённого диска. А тут сбой одного диска повреждает вообще весь массив. Это совсем не ice какой-то.
Никаких танцев. Если резервирования не было, то меняешь винт на чистый, запускаешь проверку диска, исчезнувшие данные помечаются в системе как отсутствующие, а все остальное продолжает работать. Результат тот же самый, что и без LVM. Просто тут немного подольше будут сохранившиеся данные возвращаться в онлайн.
Я, как человек с жопой с гораздо более толстым слоем ракушек, могу сказать, что RAID от исполнения танцев тоже не спасает, просто несколько снижает вероятность, зато значительно усложняет исполняемые па. ;(
Как человек собственной жопой прочувствовавший, что уровень рейда не влияет на качество фарша из данных, если того захотел контроллер — поддерживаю!
Террабайт белого шума из 4-х хардов на 5-ом рейде начисто отучили доверять передачу данных устройствам сложнее шлейфа.
чот поздновато статейка вышла… лет эдак на 8 минимум :)
вспоминаю молодость на AIX :)
Я побаиваюсь делать ЛВМ на несколько дисков без райда, ведь если умрёт один диск из массива, то с остальных инфу скорее всего уже не вытащишь.

Хотя у меня около 1.5 лет проработала связка 500+500 физические тома => 1000 логический том
зачем делать лвм на рейде? буквально выходит рейд на рейде ?!
Затем, что если в /var/lib/mysql, к примеру, место кончится, то туда можно налету добавить гуляющий шмат из /home.
В ZFS-пуле (грубо говоря — это размеченное пространство), например, можно создать отдельную файловую систему (ZFS или UFS). Потом ещё одну, ещё и ещё — сколько нужно. При этом каждая файловая система будет иметь столько свободного места, сколько осталось в пуле.

LVM может распределить тома, чтобы в каждом томе было столько же свободного места (виртуально, разумеется), сколько осталось на дисках?
Увы, будь это FS — может, и смог бы. А так — нет. На нем нарезаются разделы, которые форматятся уже в нужную фс. А-ля слайсы на разделе, которые потом форматить (раз уж вспомнили о UFS).

Меня эта задача, точнее ее решение под линухом, также интересует. Нет, я знаю про ZFS через FUSE. Но это ж не то.
Если не критична скорость, можно создать lvm на файлах 'с дырками' (sparce) когда файл на диске занимает ровно столько места, сколько в него записывали, а не сколько выделено с помощью seek.
Тормоза будут из-за реализации loop (хотя на сколько я понимаю есть альтернативы) и повышенной фрагментации (два уровня — дырявый файл фрагментируется и фрагментация самой фс).
да, можно зеркалировать один логический раздел на несколько физических
правда я всё же предпочитаю RAID1 + LVM без зеркалирования, мне кажется это проще мониторить.
Пересилил лень и решил в общем треде напомнить про unionfs, которая живет под *BSD и есть нативный порт под Linux.
Если рассуждать в масштабах проблем автора, то алгоритм такой.
Цепляем новенький террабайтник.
Форматируем и создаем на нем /home_new
Переименовываем /home в /home_old
Создаем новый /home
Unionfs монитируем на /home /home_old с правами RO и /home_new RW
Получаем х+500Gb данных
Радостно ждем, когда загнется старый диск.
Достаем новый диск (500Gb) из компа и цепляем к ноуту — «Смотри мама, все живо!»
«террабайтник» читать как «полу-террабайтник» или предположить, что мы от него только половину отформотировали под /home_new. (*иногда полезно самого себя перечитывать. иногда уже поздно*)
P.P.S. Ах, да!!! Самое главное и самый большой минус LVM — он не читается grub'ом
поэтому раздел /boot должен находиться вне LVM на отдельном разделе жёсткого диска,
иначе система не загрузится.


Хочу напомнить, что кроме grub, есть ещё и lilo который может загрузить систему даже если /boot расположен на lvm.
root@ws:~# vgcreate ws /dev/sdb
Volume group «vg0» successfully created

тут небольшой глюк — создана «ws», а не «vg0»
Ситуация:
Сделал файл, к которому привязано блочное устройство, из которого делается pvcreate, vgcreate, lvcreate, блаблабла, далее mount и ф.с. видна, дальше ей пользуется виртуалка. mount прописан в /etc/fstab/ После перезагрузки блочное устройство пропадает, физ, логические тома -тоже
Вопрос: как прописать создание блочного устройства, а затем физического тома, группы, логического тома при загрузке?
наверно не туда вопрос. Прописывать pvcreate, vgcreate, lvcreate при загрузке не нужно, один раз выполнил — и если привязать блочн. устр-во к файлу, то все тома и файловые системы на нем уже есть.
Only those users with full accounts are able to leave comments. Log in, please.