LINUX.ORG.RU

LVM на Desktop на 1 старом и 2 новыми хардами: за и против?

 , , ,


2

1

Имеется три hdd: два относительно новых WDC WD5003AZEX-00K1GA0 на 500 Gb и относительно старый ST31000528AS на 1 Tb.

Есть желание покрыть этим железом две задачи: организацию более или менее толерантного к выходу hdd из строя хранилища файлов (~100 Gb) + архив фильмов.

Планирую выделить по разделу на паре WDC и организовать RAID1 при помощи mdadm. Это решит задачу 1.

Тогда остаётся по одному разделу на WDC и вся Barracuda (допустим, там будет один большой раздел).

На ум пришли следующие пути организации:

  • LVM на все 3 раздела.

    Pros: удобно иметь единый большой раздел.

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

  • LVM на 2 раздела WDC + ФС на разделе барракуды.

    Pros: данные на паре WDC не потеряются в случае выхода из строя барракуды.

    Cons: две директории, в принципе, терпимо, хотя одна все-таки удобнее.

Опционально: так же забежала шальная мысль по mdadm raid0 на паре WDC в указанных выше связках, но, полагаю это не приведет ни к чему хорошему.

Что посоветуете? Есть истории успехов с LVM на нескольких хардах?

Уже много лет на домашней файлопомойке LVM держу. Ни одного «против» нету. Уже целиком сменился парк HDD (сначала были 2x80G+2x250G, сейчас — 1T+2T+3T). А вот «за» — очень много. Практически безостановочное обновление HDD (добавил в массив новый, вывел старый…), лёгкое расширение разделов по мере надобности, лёгкое создание новых разделов, в том числе и временных.

Давно уже каждый новый винт режется по одной технологии — отрезается небольшой раздел под boot (мало ли, операционку новую поставить), буквально 100-200Мб, остальное — под физический том и в LVM.

А вот от mdadm у меня негативные воспоминания. Капризно, хлопотно и не особенно оправдано.

KRoN73 ★★★★★
()

Юзаю в производстве связку mdadm в зеркале и поверх LVM. много лет подряд. Но все равно делаю суточные бекапы.

MikeDM ★★★★★
()

Я бы заменил raid1 бэкапом на физически другую машину и при необходимости поднял какую-нибудь кластерную ФС (небольшой оверкилл для дома/любительского сервера, но почему бы нет?). У raid1 единственное назначение — сохранить аптайм при выходе HDD из строя, мой либастрал подсказывает, что такая задача тут не стоит.

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

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

x3al ★★★★★
()
Ответ на: комментарий от KRoN73

А диски менялись из-за сбоев или морального устаревания? Если были сбои, то с какими симптомами?

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

А диски менялись из-за сбоев или морального устаревания?

Сбоев, тьфу-тьфу, не было. Меняются по мере морального устаревания.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Нафиг, нафиг, собрал как-то LVM из набора древних винчестеров, один резко двинул коней (хорошо, что dd_rescue за несколько суток смогло что-то прочитать), чуть не остался без семейного фото. Естественно, недоступна была информация со _всех_ жёстких дисков.

После этого только зеркальный raid, правда замену сбойного диска тренировал только на виртуалке. Место подходит к концу, думаю, что надо было сверху LVM запилить.

Jurik_Phys ★★★★★
()
Последнее исправление: Jurik_Phys (всего исправлений: 1)
Ответ на: комментарий от x3al

У raid1 единственное назначение — сохранить аптайм при выходе HDD из строя

А почему не сохранность данных? У меня есть некоторый опыт в работе с mdadm, а с кластерными ФС - никакого. Какие преимущества у кластерной ФС по сравнению с raid1?

omegatype ★★★
() автор топика
Ответ на: комментарий от Jurik_Phys

чуть не остался без семейного фото

Очевидно, что под семейное фото нужен бэкап. При чём — версионный бэкап. Ибо ни зеркало тебя не спасёт от удаления файлов, ни простой, не версионный бэкап — от повреждения оных.

После этого только зеркальный raid

Фигня. Потеря информации из-за отказов железа — намного менее вероятное событие, чем потеря из-за удаления/затирания/etc. Так что зеркало, как в теме было сказано, реально нужно только для безостановочной работы системы при отказе.

А так — для особо важных данных ты зеркало и на LVM поднять можешь. Но это не повод забивать на версионные бэкапы семейных фото (у меня это сейчас под 450Гб)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

А как ты выполняешь версионные бэкапы?

omegatype ★★★
() автор топика
Ответ на: комментарий от KRoN73

Что raid не отменяет бэкапов - это я в курсе. Правда руки до бэкапов не доходят. Из далека чувствую холодное дыхание «пустоты», надеясь настроить сие дело.

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

Jurik_Phys ★★★★★
()
Ответ на: комментарий от omegatype

А как ты выполняешь версионные бэкапы?

unison. Если объёмы небольшие, то прямо через сеть (ssh или nfs), если большие — то сперва rsync на машину с бэкапом и потом — версионный бэкап с неё на неё же, в другой каталог.

KRoN73 ★★★★★
()
Ответ на: комментарий от Jurik_Phys

Вообще, «клюнькающие» звуки винчестера, я гораздо чаще встречал, чем случайное удаление по неосторожности

А у меня, вот, наоборот :) Под последним, конечно, подразумевается не только буквальное удаление, но именно повреждения. За 10 лет копирования с места на место можно нарваться, скажем, на частично повреждённые фотки. Или, там, жена при редактировании сделает ресайз в web-размер и сохранит под прежним именем. Или у очередного «digikam»'а башню сорвёт и убьёт кодировку тэгов в JPEG. И т.п.

А если винт начнёт головами стучать — я его тут же из массива и выведу :)

KRoN73 ★★★★★
()
Последнее исправление: KRoN73 (всего исправлений: 1)
Ответ на: комментарий от omegatype

Какие преимущества у кластерной ФС по сравнению с raid1?

Кластерная ФС — не для этого, а для объединения того объёма, что не занят в бэкапах.

А почему не сохранность данных?

Запомни одну вещь на всю жизнь: RAID не имеет никакого отношения к сохранности данных, это — инструмент для повышения аптайма и только. Для сохранности данных есть бэкапы.

x3al ★★★★★
()
Ответ на: комментарий от KRoN73

Т.е. «версионный бэкап» - копия директории, выполненная вручную? Это как-то... не техногенно.

Мне сложно представляется юзкейс «потеря из-за удаления» при наличии в большинстве окружений «корзины», которая решает проблему сиюминутного оплошного удаления.

А если удаление не сиюминутно, то почему тогда не VCS или версионную ФС (они еще и от повреждения при случайном редактировании помогут)?

omegatype ★★★
() автор топика
Ответ на: комментарий от x3al

Кластерная ФС — не для этого, а для объединения того объёма, что не занят в бэкапах.

Тогда почему именно кластерная ФС, а не LVM?

Запомни одну вещь на всю жизнь: RAID не имеет никакого отношения к сохранности данных, это — инструмент для повышения аптайма и только. Для сохранности данных есть бэкапы.

Сохранности от аппаратного сбоя? Растолкуй подробнее почему? Сценарий «вот два харда - один сломался и данные не читаются, из-за raid1 удалось прочитать данные со второго - ура, данные спасены» кажется на поверхности, что в нём некорректно?

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

Тогда почему именно кластерная ФС, а не LVM?

Потому, что LVM over NFS (SMB, 9p для эстетов) — то ещё удовольствие для любителей BDSM (не то, чтобы это было физически невозможно: линукс всё стерпит). LVM over iSCSI — немногим лучше.

Сценарий «вот два харда - один сломался и данные не читаются, из-за raid1 удалось прочитать данные со второго - ура, данные спасены» кажется на поверхности, что в нём некорректно?

Если данные действительно важны, то их нужно сохранять не только от конкретно этого аппаратного сбоя. Если они пофиг, то RAID не нужен.

x3al ★★★★★
()
Ответ на: комментарий от omegatype

А если удаление не сиюминутно, то почему тогда не VCS или версионную ФС (они еще и от повреждения при случайном редактировании помогут)?

VCS для фото/видео — плохая идея. А инкрементальный бэкап — хорошая.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Ok, тогда для тех, кто на бронепоезде, растолкуйте более структурировано.

Есть несколько проблемных сценариев:

  • Аппаратный выход из строя HDD
  • Случайное удаление («корзину» во внимание не принимаем, допустим, что удалили месяц назад, и корзина почищена).
  • Случайное редактирование

    RAID1 не поможет от последних двух пунктов. Допустим, исключаем raid и используем бэкапы, тогда возникают вопросы:

    • Чем бэкапить? Если это rsync-подобные, то как они помогут от случайного редактирования (или удаления оригинального файла, и появления на его месте позднее другого файла под тем же именем)
    • Опять-таки, если это rsync-подобные, то мы фактически будет бэкапить не изменения в файлах, а состояния на момент бэкапа (возникает «окно» в котором полезные изменения есть, а бэкап еще не пришел). Например, слил фотки, отредактировал, потом понял, что испортил, а ночной бэкап еще не выполнен. Выполнять его «вручную» стрёмно и не комфортно - забуду в самый ответвленный момент.
    • Куда бэкапить? Если на другой HDD (не важно локальный или удаленный), то как его сохранность - если он вылетает, то вся «история» и все бэкапы улетают вместе с ним? Делать бэкап на raid1?

      Сейчас ищу информацию на вариант rait1 + версионная ФС, есть истории неуспеха?

omegatype ★★★
() автор топика
Ответ на: комментарий от x3al

Ok, тогда для тех, кто на бронепоезде, растолкуйте более структурировано.

Есть несколько проблемных сценариев:

  • Аппаратный выход из строя HDD
  • Случайное удаление («корзину» во внимание не принимаем, допустим, что удалили месяц назад, и корзина почищена).
  • Случайное редактирование

RAID1 не поможет от последних двух пунктов. Допустим, исключаем raid и используем бэкапы, тогда возникают вопросы:

  • Чем бэкапить? Если это rsync-подобные, то как они помогут от случайного редактирования (или удаления оригинального файла, и появления на его месте позднее другого файла под тем же именем)
  • Опять-таки, если это rsync-подобные, то мы фактически будет бэкапить не изменения в файлах, а состояния на момент бэкапа (возникает «окно» в котором полезные изменения есть, а бэкап еще не пришел). Например, слил фотки, отредактировал, потом понял, что испортил, а ночной бэкап еще не выполнен. Выполнять его «вручную» стрёмно и не комфортно - забуду в самый ответвленный момент.
  • Куда бэкапить? Если на другой HDD (не важно локальный или удаленный), то как его сохранность - если он вылетает, то вся «история» и все бэкапы улетают вместе с ним? Делать бэкап на raid1?

Сейчас ищу информацию на вариант rait1 + версионная ФС, есть истории неуспеха?

omegatype ★★★
() автор топика
Последнее исправление: omegatype (всего исправлений: 1)
Ответ на: комментарий от omegatype

https://wiki.archlinux.org/index.php/Backup

Опять-таки, если это rsync-подобные, то мы фактически будет бэкапить не изменения в файлах, а состояния на момент бэкапа (возникает «окно» в котором полезные изменения есть, а бэкап еще не пришел)

https://wiki.archlinux.org/index.php/Rsync#Automated_backup_with_systemd_and_...

Если на другой HDD (не важно локальный или удаленный), то как его сохранность - если он вылетает, то вся «история» и все бэкапы улетают вместе с ним?

И у нас по-прежнему остаётся копия, с которой делаем бэкап.

Делать бэкап на raid1?

LVM на Desktop на 1 старом и 2 новыми хардами: за и против? (комментарий)

https://duckduckgo.com/?q=правило 3 2 1 бэкап

x3al ★★★★★
()
Ответ на: комментарий от omegatype

Т.е. «версионный бэкап» - копия директории, выполненная вручную? Э

Где я такое писал? o_O

Чистая автоматика. Если объёмы небольшие, то один unison, если большие — то rsync + unison.

Мне сложно представляется юзкейс «потеря из-за удаления» при наличии в большинстве окружений «корзины»

Так как корзина спасёт от ошибочного ресайза картинки?

А если удаление не сиюминутно, то почему тогда не VCS или версионную ФС

VCS, которая безропотно переварит половину терабайта бинарных данных я пока не встречал.

Про «версионные ФС» не слышал уже лет 20, со времён СМ-4.

KRoN73 ★★★★★
()
Ответ на: комментарий от x3al

О! Благодарю за чудные наводки - отправился изучать.

Однако до изучения все-таки:

Automated backup with systemd and inotify

Кажется, это все-равно не поможет (такой бэкап не будет хранить историю, а значит он делает фактически тоже, что raid1):

Например, слил фотки, отредактировал, потом понял, что испортил, а ночной бэкап еще не выполнен.

  • Слил фотки (дернулся inotify и получили копию)
  • Отредактировал (дернулся inotify и обновили копию)
  • Понял, что испортил
  • Ночной бэкап еще не выполнен В бэкапе испорченная копия.
omegatype ★★★
() автор топика
Ответ на: комментарий от KRoN73

Так у тебя union выполняет функцию VCS? Или это что-то вроде:

  • my_photos_07sep31
  • my_photos_08sep31
  • my_photos_09sep31

+- архивация и удаление файлов старше порогового значения?

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

Чем бэкапить? Если это rsync-подобные, то как они помогут от случайного редактирования

Не rsync, а unison.

rsync — только вспомогательное средство, так как unison крайне медленно работает с огромными объёмами удалённых данных. Так что в этом случае тупо переносим по rsync данные с удалённой машины на локальную и уже на локальной из полученной копии делаем версионный бэкап. Избыточно получается, зато быстро :)

Куда бэкапить?

Естественно — на другую машину. В идеале — в другое географически место. А то может как у моего знакомого выйти, пришла ФСБ и вынесла _все_ носители из дому (одних HDD штук 30 набралось — он даже древние гигабайтники дома хранил :)). Только через без малого год стали по частям возвращать. Соответственно — разом лишился всей информации, что не хранилась удалённо.



Всё мечтаю о файловом доступе к терабайту места на Flickr :)

KRoN73 ★★★★★
()
Ответ на: комментарий от omegatype

Кажется, это все-равно не поможет (такой бэкап не будет хранить историю, а значит он делает фактически тоже, что raid1):

Никто не запрещает по inotify делать инкрементальную копию. А для специальных случаев (вроде часто сохраняемых файлов) можно накостылить минимальный таймаут, чтобы не хранить 1000 версий за 1 минуту.

x3al ★★★★★
()
Ответ на: комментарий от omegatype

Или это что-то вроде:

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

+- архивация и удаление файлов старше порогового значения?

Архивации нет (да и смысл для фото/видео?), количество копий — задаётся.

KRoN73 ★★★★★
()
Ответ на: комментарий от x3al

И у нас по-прежнему остаётся копия, с которой делаем бэкап.

В смысле, рабочая директория? Она может быть испорченной. Образуется другое «окно»: накосячил - решил откатиться и обнаружил, что hdd с бэкапами сам вышел из строя.

omegatype ★★★
() автор топика
Ответ на: комментарий от x3al

Никто не запрещает по inotify делать инкрементальную копию.

А вот это кажется весьма оригинальным! Взял на вооружение.

omegatype ★★★
() автор топика
Ответ на: комментарий от KRoN73

Он, если обнаруживает изменения

Изменения в каждом конкретном файле из резервируемой директории? Это фича unison?

omegatype ★★★
() автор топика
Ответ на: комментарий от omegatype

Образуется другое «окно»: накосячил - решил откатиться и обнаружил, что hdd с бэкапами сам вышел из строя.

3-2-1.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Дорого. Получается, что без 3-2-1 бэкапы, в принципе, ничем не лучше raid1.

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

omegatype ★★★
() автор топика
Ответ на: комментарий от KRoN73

Класс, отличная наводка - благодарю!

omegatype ★★★
() автор топика
Ответ на: комментарий от KRoN73

А вот от mdadm у меня негативные воспоминания. Капризно, хлопотно и не особенно оправдано.

Использую mdadm raid1, за 5 лет ни малейших проблем не было. Диски вылетали, диски менял. Вот с raid5 пока опыт негативный.

router ★★★★★
()
Ответ на: комментарий от x3al

У raid1 единственное назначение — сохранить аптайм при выходе HDD из строя

Как минимум ещё удвоение производительности на чтение ( read iops )

router ★★★★★
()
Ответ на: комментарий от KRoN73

А как быть в таком случае http://www.linux.org.ru/forum/general/9435587. Как я понял ТС так и не восстановил ФС. Мне интерестно, можно ли, вообще, восстановить фс полсле того как один из дисков лвм упадет.

И каким образом происходит замена жесткого диска в рабочей системе?

igor_kr
()

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

$ lsblk                                                                       ~
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                     8:0    0 931.5G  0 disk  
├─sda1                  8:1    0    30G  0 part  
│ └─md0                 9:0    0    60G  0 raid0 
│   ├─lvm-root (dm-0) 253:0    0    16G  0 lvm   /
│   ├─lvm-var (dm-2)  253:2    0     4G  0 lvm   /var
│   ├─lvm-opt (dm-3)  253:3    0    16G  0 lvm   /opt
│   └─lvm-swap (dm-4) 253:4    0     8G  0 lvm   [SWAP]
└─sda2                  8:2    0   900G  0 part  
  └─md1                 9:1    0   1.8T  0 raid0 
    └─home (dm-1)     253:1    0   1.8T  0 crypt /home
sdb                     8:16   0 931.5G  0 disk  
├─sdb1                  8:17   0    30G  0 part  
│ └─md0                 9:0    0    60G  0 raid0 
│   ├─lvm-root (dm-0) 253:0    0    16G  0 lvm   /
│   ├─lvm-var (dm-2)  253:2    0     4G  0 lvm   /var
│   ├─lvm-opt (dm-3)  253:3    0    16G  0 lvm   /opt
│   └─lvm-swap (dm-4) 253:4    0     8G  0 lvm   [SWAP]
└─sdb2                  8:18   0   900G  0 part  
  └─md1                 9:1    0   1.8T  0 raid0 
    └─home (dm-1)     253:1    0   1.8T  0 crypt /home
Так что делай как удобнее, бэкапы всегда спасут.

Gotf ★★★
()
Ответ на: комментарий от igor_kr

И каким образом происходит замена жесткого диска в рабочей системе?

Втыкаем новый винт. Обычно системы горячее подключение не поддерживают, так что приходится ненадолго выключать.

После включения и загрузки, прямо в работающей системе:
— Создаём на новом диске физический том (pv)
— Расширяем lvm-том на этот физический том (lvextend)
— Перемещаем со старого физического тома все данные в новый/другие (pvmove)
— Выводим старый физический том из lvm (lvreduce)
— Всё, старый диск больше не используется. Можно выключить и выдернуть.

Если диски поддерживают горячую замену, то всё можно сделать без выключения. Если горячей замены нет, то выключать приходится дважды, но ненадолго, фактически — только на время перезагрузки. На время длительных операций копирования система остаётся в работе.

Знаю только один нюанс — у меня почему-то процесс pvmove всегда зависал при переносе /var (данные при этом не повреждались). Ошибку никто не подтвердил, у других переносится нормально, а вот у меня — всегда так. Так что в тех редких случаях, когда /var переносился, приходилось грузиться с live-usb. Хорошо ещё, что раздел маленький (/var/portage, /var/lib и другие — у меня все на отдельных разделах)

KRoN73 ★★★★★
()
Ответ на: комментарий от Gotf

$ lsblk

О, блин! Век живи…

# lsblk
NAME                                 MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                    8:0    0   2,7T  0 disk 
├─sda1                                 8:1    0     2M  0 part 
├─sda2                                 8:2    0   2,1T  0 part 
│ ├─balvg-video3 (dm-2)              253:2    0   1,5T  0 lvm  /home/family/Video
│ ├─balvg-family_our (dm-3)          253:3    0   514G  0 lvm  /home/family/Our
│ ├─balvg-backup3 (dm-4)             253:4    0   260G  0 lvm  /home/backup
│ ├─balvg-music2 (dm-5)              253:5    0 109,6G  0 lvm  /home/family/Music
│ ├─balvg-airbase (dm-8)             253:8    0   400G  0 lvm  
│ ├─balvg-gentoo64--root (dm-11)     253:11   0    10G  0 lvm  /
│ ├─balvg-gentoo64--usr (dm-12)      253:12   0    30G  0 lvm  /usr
│ ├─balvg-gentoo64--var (dm-13)      253:13   0    20G  0 lvm  /var
│ ├─balvg-gentoo64--var--lib (dm-14) 253:14   0    40G  0 lvm  /var/lib
│ ├─balvg-gentoo64--var--www (dm-15) 253:15   0    30G  0 lvm  /var/www
│ ├─balvg-gentoo64--home (dm-16)     253:16   0    80G  0 lvm  /home
│ ├─balvg-swap (dm-17)               253:17   0     8G  0 lvm  [SWAP]
│ ├─balvg-lxc--test--debian (dm-18)  253:18   0    10G  0 lvm  
│ ├─balvg-lxc--dispatcher (dm-19)    253:19   0     5G  0 lvm  
│ ├─balvg-astro (dm-20)              253:20   0   150G  0 lvm  /home/family/Astro
│ ├─balvg-airbase--lxc (dm-21)       253:21   0   220G  0 lvm  
│ ├─balvg-lxc--hosting (dm-22)       253:22   0    20G  0 lvm  
│ ├─balvg-works (dm-23)              253:23   0     5G  0 lvm  
│ ├─balvg-lxc--common (dm-24)        253:24   0    20G  0 lvm  
│ ├─balvg-portage (dm-25)            253:25   0    30G  0 lvm  /var/portage
│ ├─balvg-lxc--balabot (dm-26)       253:26   0    10G  0 lvm  
│ └─balvg-lxc--airbase--dev (dm-27)  253:27   0    10G  0 lvm  /etc/lxc/airbase-dev/rootfs
├─sda3                                 8:3    0   695G  0 part 
└─sda4                                 8:4    0   498M  0 part 
sdb                                    8:16   0   1,8T  0 disk 
├─sdb1                                 8:17   0   100G  0 part 
│ ├─balvg-gentoo64--root (dm-11)     253:11   0    10G  0 lvm  /
│ ├─balvg-gentoo64--usr (dm-12)      253:12   0    30G  0 lvm  /usr
│ ├─balvg-gentoo64--var (dm-13)      253:13   0    20G  0 lvm  /var
│ └─balvg-gentoo64--var--lib (dm-14) 253:14   0    40G  0 lvm  /var/lib
└─sdb2                                 8:18   0   1,7T  0 part 
  ├─balvg-small_files (dm-1)         253:1    0   130G  0 lvm  /mnt/data/small-files
  ├─balvg-video3 (dm-2)              253:2    0   1,5T  0 lvm  /home/family/Video
  ├─balvg-family_our (dm-3)          253:3    0   514G  0 lvm  /home/family/Our
  ├─balvg-backup3 (dm-4)             253:4    0   260G  0 lvm  /home/backup
  ├─balvg-family (dm-6)              253:6    0   170G  0 lvm  /home/family
  ├─balvg-files (dm-7)               253:7    0   150G  0 lvm  /home/family/Files
  ├─balvg-data (dm-9)                253:9    0    70G  0 lvm  /data
  └─balvg-aviaport (dm-10)           253:10   0    22G  0 lvm  
sdc                                    8:32   0 931,5G  0 disk 
├─sdc1                                 8:33   0    50G  0 part 
│ ├─balvg-gentoo64--root (dm-11)     253:11   0    10G  0 lvm  /
│ ├─balvg-gentoo64--usr (dm-12)      253:12   0    30G  0 lvm  /usr
│ ├─balvg-gentoo64--var (dm-13)      253:13   0    20G  0 lvm  /var
│ └─balvg-gentoo64--var--lib (dm-14) 253:14   0    40G  0 lvm  /var/lib
└─sdc2                                 8:34   0 881,5G  0 part 
  ├─balvg-downloads2 (dm-0)          253:0    0   400G  0 lvm  /home/family/Downloads
  ├─balvg-small_files (dm-1)         253:1    0   130G  0 lvm  /mnt/data/small-files
  ├─balvg-video3 (dm-2)              253:2    0   1,5T  0 lvm  /home/family/Video
  ├─balvg-family (dm-6)              253:6    0   170G  0 lvm  /home/family
  └─balvg-files (dm-7)               253:7    0   150G  0 lvm  /home/family/Files
sdd                                    8:48   0 232,9G  0 disk 
├─sdd1                                 8:49   0   100M  0 part 
└─sdd2                                 8:50   0 232,8G  0 part /media/Win7

KRoN73 ★★★★★
()
Ответ на: комментарий от igor_kr

Оказывается, все просто.

Тем она и интересна :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.