LVM опасности и оговорки

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

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

174 голоса | спросил Adam Matan 12 J0000006Europe/Moscow 2011, 11:34:52

4 ответа


237

Резюме

Риски использования LVM:

  • Уязвим к записи проблем кэширования с помощью гипервизора SSD или VM
  • Сложнее восстановить данные из-за более сложных структур на диске.
  • Сложно изменить размеры файловых систем правильно
  • Снимки сложны в использовании, медленны и багги
  • Требуется определенное умение правильно настроиться с учетом этих проблем.

Первые две проблемы LVM объединяются: если кэширование записи работает некорректно, и у вас есть потеря мощности (например, из-за отказа PSU или UPS), вам может потребоваться восстановить резервную копию, что означает значительное время простоя. Ключевой причиной использования LVM является повышенное время безотказной работы (при добавлении дисков, изменении размеров файловых систем и т. Д.), Но важно правильно настроить кэширование записи, чтобы избежать LVM, фактически снижая время безотказной работы.

- Обновлен сентябрь 2017 года: стал менее заметным старый материал ядра

Смягчение рисков

LVM может работать хорошо, если вы:

  • Получите настройку кэширования записи прямо в гипервизоре, ядре и SSD.
  • Избегать снимков LVM
  • Использовать последние версии LVM для изменения размеров файловых систем.
  • Хорошие резервные копии

Подробнее

Я исследовал это довольно немного в прошлом, испытав потерю данных, связанных с LVM. Основные риски и проблемы LVM, о которых я знаю, следующие:

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

  • Запись кэширования и перезаписывание записи с жесткого диска важна для хорошей производительности, но может не правильно очистить блоки на диске из-за гипервизоров VM, кэширования на жестком диске, старых ядер Linux и т. д.
    • Записывать барьеры означает, что ядро ​​гарантирует, что оно завершит определенные записи на диске до «барьера», disk write, чтобы обеспечить восстановление файловых систем и RAID в случае внезапной потери питания или сбоя. Такие барьеры могут использовать операцию FUA для немедленной записи определенных блоков на диск, что более эффективен, чем полный кеш-флеш. Барьеры могут сочетаться с эффективными с тегами / native (выдача нескольких запросов ввода-вывода на диске одновременно), чтобы включить жесткий диск для интеллектуального перезаписывания записи без увеличения риска потери данных.
  • Гипервизоры VM могут иметь схожие проблемы: запуск LVM в гостевой ОС Linux поверх гипервизора VM, такого как VMware, Xen , KVM, Hyper-V или VirtualBox могут создавать схожие проблемы с ядром без барьеров записи из-за кэширования записи и записи Последующий заказ. Внимательно проверьте свою гипервизорную документацию для «флеш-диска» или параметра кэширования записи (присутствует в KVM , VMware , Xen , VirtualBox и другие) - и протестируйте его с помощью вашей настройки. Некоторые гипервизоры, такие как VirtualBox, имеют параметр по умолчанию , который игнорирует любые флеши на диске от гостя.
  • Серверы предприятия с LVM должны всегда использовать аккумуляторный RAID-контроллер и отключите кэширование записи на жестком диске (у контроллера есть резервная копия с резервной батареей, которая является быстрой и безопасной) - см. этот комментарий автором этой записи в FAQ XFS . Также может быть безопасно отключить барьеры записи в ядре, но рекомендуется тестирование.
  • Если у вас нет RAID-контроллера с батарейным питанием, отключение кэширования записи на жесткий диск замедлит запись, но сделает LVM безопасным. Вы также должны использовать эквивалентопции ext3 data = ordered (или data = journal для дополнительной безопасности), плюс барьер = 1, чтобы гарантировать, что кеширование ядра не влияет целостность. (Или используйте ext4, который включает барьеры по умолчанию ). Это самый простой и обеспечивает хорошую целостность данных по стоимости исполнения. (Linux изменил опцию по умолчанию ext3 на более опасный data = writeback a назад, поэтому не полагайтесь на настройки по умолчанию для FS.)
  • Чтобы отключить кэширование записи на жесткий диск : добавьте hdparm -q -W0 /dev /sdX для всех дисков в /etc/rc.local (для SATA) или использовать sdparm для SCSI /SAS. Однако, согласно этой записи в FAQ XFS (что очень хорошо по этой теме), диск SATA может забыть этот параметр после восстановления ошибки диска - поэтому вы должны использовать SCSI /SAS, или если вы должны использовать SATA, тогда установите команду hdparm в задание cron, работающее каждую минуту или около того.
  • Чтобы сохранить кэширование записи на SSD /жестком диске, включено для повышения производительности: это сложная область - см. раздел ниже.
  • Если вы используете диски Advanced Format , то есть 4 КБ физических секторов, см. ниже - отключение кэширования записи может иметь другие проблемы.
  • ИБП имеет решающее значение как для предприятия, так и для SOHO, но недостаточно для обеспечения безопасности LVM: все, что может привести к серьезному сбою или потере питания (например, отказ ИБП, отказ блока питания или истощение батареи), может потерять данные в кэш жестких дисков.
  • Очень старые ядра Linux (2.6.x с 2009 г.) . Существует неполная поддержка барьера для записи в очень старых версиях ядра 2.6.32 и более ранних версиях ( 2.6.31 имеет некоторую поддержку , а RHEL 6 использует 2.6.32 со многими патчами. Если эти старые ядра ядра не загружены для этих проблем, большое количество метаданных FS (включая журналы) может быть потеряно из-за жесткого сбоя, который оставляет данные в буферах записи на жестких дисках (скажем, 32 МБ на диск для обычных дисков SATA). Потеря 32 МБ из недавно написанных метаданных FS и данных журнала, которые, по мнению ядра, уже находятся на диске, обычно означает много коррупции FS и, следовательно, потерю данных.
  • Сводка: вы должны позаботиться о файловой системе, RAID-массиве, гипервизоре VM и жестком диске /SSD-настройке, используемой с LVM. У вас должны быть очень хорошие резервные копии, если вы используете LVM, и обязательно создавайте резервные копии метаданных LVM, физических разделов, MBR и загрузочных секторов. Также рекомендуется использовать диски SCSI /SAS, поскольку они менее склонны лгать о том, как они пишут кэширование - для использования дисков SATA требуется больше внимания.

Сохранение кэширования записи включено для производительности (и для управления лежащими дисками)

Более сложная, но эффективная опция заключается в том, чтобы активировать кэширование записи на SSD /жестком диске и полагаться на барьеры записи ядра, работающие с LVM, на ядре 2.6.33+ (двойная проверка путем поиска «барьерных» сообщений в журналах).

Вы также должны убедиться, что настройка RAID, настройка гипервизора VM и файловая система используют барьеры записи (т.е. требует, чтобы диск очищал ожидающие записи до и после записи метаданных /журналов ключей). XFS действительно использует барьеры по умолчанию, но ext3 не , поэтому с ext3 вы должны использовать барьер = 1 в настройках монтирования и по-прежнему использовать data = ordered или data = journal, как указано выше.

  • К сожалению, некоторые жесткие диски и SSD описывают, действительно ли они сбросили кеш на диск (особенно старые диски, но в том числе некоторые диски SATA и некоторые корпоративные SSD ) - подробнее здесь . Существует отличное резюме от разработчика XFS .
  • простой инструмент тестирования для лживых дисков (скрипт Perl) или см. этот фон с другим инструментом , проверяющим переупорядочение записи в результате кэша диска. <аhref = "https://serverfault.com/questions/266360/making-sata-disk-write-cache-safe"> Этот ответ охватывал аналогичное тестирование дисков SATA, которые обнаружили проблему барьера для записи в программном RAID - эти тесты фактически реализуют весь стек хранилища.
  • Более свежие диски SATA, поддерживающие Собственная очередь команд (NCQ) могут быть менее вероятно, чтобы лежать - или, возможно, они выполняют ну, без кэширования записи из-за NCQ, и очень немногие диски не могут отключить кэширование записи.
  • Диски SCSI /SAS в целом нормальны, так как они не нуждаются в кешировании записи, чтобы хорошо работать (через SCSI Tagged Command Queuing , аналогично NCQ от SATA).
  • Если ваши жесткие диски или твердотельные накопители лгут о том, чтобы очистить свой кеш на диске, вы действительно не можете полагаться на барьеры записи и должны отключать кэширование записи. Это проблема для всех файловых систем, баз данных, менеджеров томов и программного обеспечения RAID , а не только LVM.

SSD являются проблематичными, поскольку использование кеша записи имеет решающее значение для срока службы SSD. Лучше использовать SSD, у которого есть суперконденсатор (чтобы включить очистку кеша при сбое питания и, следовательно, включить кеш, чтобы он не записывал запись).

Расширенный формат настройка диска - кэширование записи, выравнивание, RAID, GPT

Сложнее восстановить данные из-за более сложных структур на диске :

  • Любое восстановление данных LVM, требуемое после жесткого сбоя или потери мощности (из-за неправильного кэширования записи), в лучшем случае является ручным процессом, поскольку, по-видимому, нет подходящих инструментов. LVM поддерживает резервное копирование метаданных в /etc /lvm, что может помочь восстановить базовую структуру LV, VG и PV, но не поможет с потерянными файловыми метаданными.
  • Следовательно, возможно, потребуется полное восстановление из резервной копии. Это связано с гораздо большим временем простоя, чем с быстрым фальшивым журналом, когда не используется LVM, а данные, записанные с момента последней резервной копии, будутпотеряны.
  • TestDisk , ext3grep , ext3undel и другие инструменты могут восстанавливать разделы и файлы с дисков, отличных от LVM, но они напрямую не поддерживают восстановление данных LVM. TestDisk может обнаружить, что потерянный физический раздел содержит LVM PV, но ни один из этих инструментов не понимает логические тома LVM. File carving инструменты, такие как PhotoRec , и многие другие будут работать, поскольку они обходят файловую систему для повторной сборки файлов из блоков данных, но это последний подход к низкоуровневым ценным данным и хуже работает с фрагментированными файлами.
  • В некоторых случаях возможно восстановление вручную LVM, но оно сложное и трудоемкое - см. этот пример и этот , это и этот для восстановления.

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

  • Обновление: . Более свежие версии lvextend поддерживают опцию -r (- resizefs) - если это доступно , это более безопасный и быстрый способ изменения размера LV и файловой системы, особенно если вы сокращаете FS, и вы можете в основном пропустить этот раздел.
  • Большинство руководств по изменению размера FSS на базе LVM не учитывают тот факт, что FS должен быть несколько меньше размера LV: подробное объяснение здесь . При сжатии файловой системы вам нужно будет указать новый размер для инструмента изменения размера FS, например. resize2fs для ext3 и lvextend или lvreduce. Без особой осторожности размеры могут быть несколько разными из-за разницы между 1 ГБ (10 ^ 9) и 1 GiB (2 ^ 30), или как различные инструменты вокруг размеров вверх или вниз.
  • Если вы не выполняете вычисления точно (или используйте некоторые дополнительные шаги за пределами наиболее очевидных), вы можете оказаться в FS, который слишком велик для LV. Все будет выглядеть отлично в течение нескольких месяцев или лет, пока вы полностью не заполните FS, и в этот момент вы получите серьезную коррупцию. И если вы не знаете об этой проблеме, трудно понять, почему, поскольку к тому времени вы также можете иметь реальные ошибки в диске которые окутывают ситуацию. (Возможно, эта проблема влияет только на уменьшение размера файловых систем - однако ясно, что изменение размеров файловых систем в любом направлении увеличивает риск потери данных, возможно, из-за ошибки пользователя.)
  • Похоже, что размер LV должен быть больше размера FS на 2 x размер физической протяженности LVM (PE), но проверьте ссылку выше для деталей, поскольку источник для этого не является авторитетным. Часто допускается 8 MiB, но может быть лучше разрешить больше, например. 100 MiB или 1 GiB, чтобы быть в безопасности. Чтобы проверить размер PE и ваш логический том + размеры FS, используйте 4 байта KiB = 4096 байтов:

    Показывает размер PE в KiB:
    vgdisplay --units k myVGname | grep «Размер PE»

    Размер всех LV:
    lvs --units 4096b

    > Размер (ext3) FS, предполагает 4 блока KiB FS:
    tune2fs -l /dev /myVGname /myLVname | grep «Количество блоков»

  • В отличие от него, установка без LVM делает изменение размера FS очень надежным и простым - Gparted и измените размер необходимых FS, тогда он сделает все для вас. На серверах вы можете использовать parted из оболочки.

    • Лучше всего использовать Gparted Live CD или Parted Magic , так как они имеют недавно и часто более без ошибок Gparted & ядро, чем дистрибутивверсия - я однажды потерял целую FS из-за того, что Gparted дистрибутива не обновлял разделы правильно в запущенном ядре. Если вы используете дистрибутив Gparted, обязательно перезагрузитесь сразу же после изменения разделов, чтобы представление ядра было правильным.

Снимки сложны в использовании, медленны и багги - если моментальный снимок заканчивается из предварительно выделенного пространства, это автоматически отбрасывается . Каждый снимок данного LV является дельтам против этого LV (а не против предыдущих снимков), который может потребовать много места при мгновенной съемке файловых систем со значительной активностью записи. Безопасно создать снимок LV, размер которого совпадает с оригинальным LV, так как снимок тогда не будет исчерпан.

Снимки также могут быть очень медленными (в 3-6 раз медленнее, чем без LVM для эти тесты MySQL ) - см. этот ответ охватывающих различные проблемы с моментальным снимком . Медленность частично связана с тем, что моментальные снимки требуют много синхронных записей .

Снимки имеют некоторые существенные ошибки, например. в некоторых случаях они могут сделать загрузку очень медленной или привести к сбою в завершении полностью (потому что ядро ​​может отключиться , ожидая корневой FS, когда это Снимок LVM [исправлено в Debian initramfs-tools update, март 2015]).

  • Один из показателей заключается в том, что существует множество ошибок Debian соответствие" lvm snapshot 2015 ", некоторые из них довольно серьезны - однако многие ошибки состояния моментальной копии имеют, по-видимому, исправлено . LVM без снимков, как правило, довольно хорошо отлаживается, возможно, потому, что моментальные снимки не используются так сильно, как основные функции.

Альтернативы снимков - файловые системы и гипервизоры VM

VM /облачные снимки:

  • Если вы используете гипервизор VM или облачный провайдер IaaS, их моментальные снимки (например, снимки VMware, VirtualBox или Amazon EC2 EBS) часто являются намного лучшей альтернативой снимкам LVM. Вы можете с легкостью сделать снимок для целей резервного копирования (но подумайте о замораживании FS до того, как вы это сделаете).

Снимки файловой системы:

  • моментальные снимки уровня файловой системы с ZFS или btrfs просты в использовании и обычно лучше, чем LVM, и хотя ни одна из файловых систем не очень зрелая в Linux, они могут быть лучшим вариантом для людей, которым действительно нужны снимки без перехода на виртуальный /облачный маршрут:

    • ZFS: теперь существует реализация ядра ZFS , которая использовалась в течение нескольких лет и должна быть много быстрее, чем ZFS в FUSE.
    • btrfs не совсем готов к использованию, а fsck и repair инструменты все еще находятся в разработке.

Снимки для онлайн-резервных копий и fsck

Снимки могут использоваться для обеспечения согласованного источника для резервных копий, если вы будете осторожны с выделенным пространством (в идеале, моментальный снимок будет такого же размера, как и резервное копирование LV). Отличный rsnapshot (начиная с версии 1.3.1) даже управляет созданием /удалением моментальных снимков LVM для вас - см. Этот HOWTO на rsnapshot с использованием LVM . Однако обратите внимание на общие проблемы с моментальными снимками и что снимок не должен считаться резервной копией сам по себе.

Вы также можете использовать моментальные снимки LVM для создания онлайн-фс: снимок LV и fsck для моментального снимка, при этом все еще используется основной не-снимок FS - , описанный здесь - однако это не совсем прямолинейно , поэтому лучше всего использовать e2croncheck как описанный Тедом Цо , сопровождающим ext3.

Вы должны временно заморозить файловую систему при съемке моментальных снимков - некоторые файловые системы, такие как поскольку ext3 и XFS будут делать это автоматически , когда LVM создает моментальный снимок.

Выводы

Несмотря на это, я все еще использую LVM в некоторых системах, но для настройки рабочего стола предпочитаю сырые разделы. Основным преимуществом, которое я могу видеть из LVM, является гибкость перемещения и изменения размера FSs , когда вы должны иметь высокую работоспособность на сервере - если вам это не нужно, gparted проще и имеет меньший риск данных потеря.

LVM требует большой осторожности при настройке кэширования записи из-за гипервизоров VM, кэширования жесткого диска /SSD-записи и т. д. - но то же самое относится к использованию Linux в качестве сервера БД. Отсутствие поддержки большинства инструментов (gparted, включая вычисления критического размера, и testdisk и т. Д.) Затрудняет использование, чем должно быть.

Если вы используете LVM, обратите внимание на моментальные снимки: используйте моментальные снимки VM /Cloud, если это возможно, или исследуйте ZFS /btrfs, чтобы полностью избежать LVM - вы можете обнаружить, что ZFS или btrs достаточно зрелы по сравнению с LVM со снимками.

Итог: если вы не знаете о перечисленных выше проблемах и как их решать, лучше не использовать LVM.

ответил RichVel 12 J0000006Europe/Moscow 2011, 12:19:04
15

I [+1], что сообщение, и, по крайней мере, для меня, я думаю, что большинство проблем существует. Видите их при запуске нескольких 100 серверов и нескольких 100TB данных. Для меня LVM2 в Linux похож на «умную идею» у кого-то. Как и некоторые из них, они иногда оказываются «неумными». То есть не имеющие строго разделенного ядра и пользовательского пространства (lvmtab), могли бы чувствовать себя действительно умными, чтобы покончить с ними, потому что могут быть проблемы с коррупцией (если вы не получите код справа)

Ну, просто это разделение было по какой-либо причине - различия проявляются с обработкой потерь PV и онлайн-повторной активацией VG, т. е. отсутствующими PV, чтобы вернуть их в игру - Что это легкий ветерок на «оригинальных LVM» (AIX, HP-UX) превращается в дерьмо на LVM2, так как обработка состояния недостаточно хороша. И даже не заставляйте меня говорить об обнаружении потерь в кворуме (ха-ха) или обработке состояния (если я удалю диск, который не будет помечен как недоступный. У него даже есть статус проклятия столбец)

Re: стабильность pvmove ... почему

  

потеря данных pvmove

такая статья высокого рейтинга на моем блоге, хммм? Только сейчас я смотрю на диск, где данные phyiscal lvm по-прежнему находятся на штате с середины pvmove. Я думаю, что были некоторые memleaks, и общая идея, что хорошо скопировать вокруг живых данных блоков из пользовательского пространства, просто грустно. Хорошая цитата из списка lvm «похоже на vgreduce - смешение не обрабатывает pvmove» Значит, если диск отсоединяется во время pvmove, тогда инструмент управления lvm изменяется с lvm на vi. О, и там также была ошибка, когда pvmove продолжается после ошибки чтения /записи блока и фактически не записывает данные на целевое устройство. WTF?

Re: Snapshots CoW выполняется небезопасно, обновляя НОВЫЕ данные в области снимка lv и затем объединяясь, как только вы удаляете привязку. Это означает, что у вас большие всплески IO во время окончательного слияния новых данных в исходном LV, и, что более важно, вы, конечно, также имеете гораздо более высокий риск повреждения данных, потому что не будет снижаться моментальный снимок, стены, но оригинал.

Преимущество заключается в производительности, делая 1 запись вместо 3. Выбор быстрого, но ненадежного алгоритма - это то, что, очевидно, ожидает от таких людей, как VMware и MS, на «Unix», я предпочел бы, что все будет сделано правильно ». Я не видел больших проблем с производительностью, пока у меня есть хранилище резервных копий снимков на диске different , чем первичные данные (и резервное копирование на еще один, конечно)

Re: Барьеры Я не уверен, можно ли винить это в LVM. Насколько я знаю, это была проблема devmapper. Но может быть какая-то виновата в том, что она не заботится об этой проблеме, по крайней мере, с ядра 2.6 до 2.6.33 AFAIK Xen - единственный гипервизор, который использует O_DIRECT для виртуальных машин, проблема была когда «цикл» использовался, потому что ядро ​​все равно будет кэшировать с этим. Virtualbox по крайней мере имеет некоторые настройки для отключения таких вещей, и Qemu /KVM, как правило, позволяет кэшировать. У всех FUSE FS также есть проблемы (нет O_DIRECT)

Re: Размеры Я думаю, LVM делает «округление» отображаемого размера. Или он использует GiB. Во всяком случае, вам нужно использовать размер VG Pe и умножить его на LE-номер LV. Это должно дать правильный размер сети, и эта проблема всегда является проблемой использования. Это ухудшается файловыми системами, которые не замечают такую ​​вещь во время fsck /mount (hello, ext3) или не работают в режиме онлайн «fsck -n» (hello, ext3)

Конечно, это говорит о том, что вы не можете найти хорошие источники для такой информации. «сколько LE для VRA?» «что такое фискальное смещение для PVRA, VGDA, ... и т. д.»

По сравнению с оригинальным LVM2 является ярким примером «Те, кто не понимает UNIX, обречены на повторное использование, плохо».

Обновите несколько месяцев спустя: я уже использовал сценарий «полного моментального снимка» для теста. Если они заполняются, блоки моментальных снимков, а не оригинальные LV. Я был неправ там, когда я впервые опубликовал это. Я взял неправильную информацию из какого-то документа, или, может быть, я это понял. В моих установках я всегда был очень параноидальным, чтобы не позволить им пополняться, и поэтому я никогда не исправлялся. Также возможно продлить /сжать снимки, что является удовольствием.

То, что мне еще не удалось решить, - это определить возраст моментального снимка. Что касается их производительности, на странице проекта «thinp» Fedora есть заметка, в которой говорится, что технология моментальных снимков пересматривается, чтобы они не становились медленнее с каждым снимком. Я не знаю, как они его реализуют.

ответил Florian Heigl 11 SunEurope/Moscow2011-12-11T18:03:57+04:00Europe/Moscow12bEurope/MoscowSun, 11 Dec 2011 18:03:57 +0400 2011, 18:03:57
12

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

btw, если вы собираетесь использовать 1TB-диск, помните о выравнивании разделов - этот диск, скорее всего, имеет 4KB физических секторов.

ответил pQd 12 J0000006Europe/Moscow 2011, 13:44:59
5

Адам,

Еще одно преимущество: вы можете добавить новый физический том (PV), перенести все данные на это PV и затем удалить старый PV без каких-либо перерывов в работе. Я использовал эту способность как минимум четыре раза за последние пять лет.

Недостаток, о котором я еще не заметил, ясно показал: для LVM2 есть несколько крутая кривая обучения. В основном в абстракции он создает между вашими файлами и основным носителем. Если вы работаете с несколькими людьми, которые разделяют обязанности на множестве серверов, вы можете найти дополнительную сложность, подавляющую вашу команду в целом. Большие команды, посвященные ИТ-работе, как правило, не будут иметь такой проблемы.

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

Следует обратить особое внимание на то, что если вы загружаетесь с логического тома LVM2, вы делали операции восстановления на месте сложными при сбое сервера. У Knoppix и друзей не всегда есть подходящие вещи для этого. Итак, мы решили, что наш каталог /boot будет на своем собственном разделе и всегда будет небольшим и родным.

В целом, я поклонник LVM2.

ответил Mike Diehn 23 J0000006Europe/Moscow 2011, 01:03:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132