Алексей Федорчук - Linux Mint и его Cinnamon. Очерки применителя

• Название: Linux Mint и его Cinnamon. Очерки применителя
• Автор: Алексей Федорчук
• Жанр: Программное обеспечение

---

Во вкладке Имена файлов определяется система именования файлов, полученных в результате оцифровки. Я оставил умолчания программы без изменений — они понятны без комментариев:

Далее, во вкладке Кодирование, указываются форматы выходных файлов — мне было достаточно сжатого с потерями MP3 и сжатого lossless, FLAC:

При желании можно указать ещё несколько форматов, в том числе и с использованием проприетарного кодека Nero — правда, все они потребуют доустановки соответствующих пакетов:

Во вкладке Расширенные я оставил умолчания без изменений, включив только на всякий случай запись log-файла:

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

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

Впрочем, один из дисков набора прочитался почему-то по человечески:

Теперь оставалось только нажать кнопку Извлечь — и наблюдать за ходом процесса, который может занять немалое время, не смотря на то, что считывание трака и его кодирование осуществляются параллельно:

Однако рано или поздно процесс заканчивается, что знаменуется соответствующим сообщением:

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

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

softRAID, LVM, ZFS

Следующие три очерка посвящаются рассмотрению довольно специальных вопросов — применению в Mint программного RAID, технологии LVM и системы размещёния данных ZFS. Тех, кого эти темы не интересуют, могут смело пропустить соответствующие страницы.

Общее введение

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

   1. программный RAID, позволяющий повысить быстродействие дисковой подсистемы (softRAID Level 0);

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

   3. система размещёния данных ZFS, объединяющая в себе функции управления логическими томами и файловой системы.

Возможны и другие варианты, например, softRAID Level 1, обеспечивающий, опять же при некоторых условиях, надёжность хранения данных, или файловая система BTRFS, функцйионально сходная с ZFS. Однако первое решение для настольной машины (а в данных очерках рассматривается только этот случай, о серверах тут речи не будет) имеет не много смысла. Ибо эта самая надёжность гарантируется только тогда, когда есть возможность замены вышедшего из сторя диска аналогичным по объёму и, желательно, характеристикам — согласитесь, не частое явление для индивидуала-надомника.

Что же до BTRFS — что бы ни говорили о готовности этой системы к промышленному использованию (а настольная машина применителя для него самое что ни на есть промышленное использование), на сей счёт в народе (в том числе и у автора этих строк) существуют небезосновательные сомнения. Характерно, что в openSUSE, кажется, первой взявшей BTRFS на вооружение как умолчальной, она задействуется под корневую файловую систему, тогда как бесценные пользовательские данные по умолчанию предлагается размещать на XFS.

В силу вышесказанного в настоящей книге рассмотрены только три перечисленных варианта. Каждый из них имеет свои преимущества и недостатки. И поэтому ни один из них не может быть однозначно рекомендован во всех случаях жизни. Надеюсь, что следующие очерки дадут читателю некоторую информацию для того, чтобы выбрать вариант, подходящий именно для него. Своё же мнение по сравнению их я выскажу в общем заключении.

И ещё одна необходимая оговорка: все три варианта я рассматриваю исключительно в контексте хранения пользовательских данных, то есть, фигурально говоря, ветви /home файловой иерархии. Предполагается, что корень последней размещён на обычном дисковом разделе с традиционной файловой системой, которая, как говаривал Генри Форд Старший, может быть любой. При условии, что это будет Ext4, ибо все остальные нынче не дадут применителю ничего, кроме возможных проблем, в причины возникновения которых здесь вдаваться неуместно. А вот сказать пару слов об инструментах дисковой разметки — необходимо.

Инструменты дисковой разметки и форматирования

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

Виды дисковой разметки

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

«Потом пришли другие времена» — и необходимость в столь подробных описаниях отпала. Да и число актуальных схем дисковой разметки резко поуменьшилось, сведясь к двум с половиной вариантам:

   1. разметка в стиле msdos;

   2. разметка в стиле gpt;

   3. полварианта для любителей и ценителей — разметка в стиле bsd.

На полуварианте останавливаться не буду — те, кто держит на своей машине Linux параллельно с какой-либо BSD-системой, знают о нём не меньше меня. Тем более, что это, как и msdos, частный случай MBR-разметки, о которой сказать необходимо.

Разметка в стиле msdos возникла вместе с первыми IBM PC и их BIOS, предусматривающим Главную Загрузочную Запись (MBR — Master Boot Record). Она целиком умещается в так называемый нулевой сектор носителя, объёмом 512 байт. И в его части, отведённой под таблицу разделов, предусмотрено место для четырёх записей — то есть Primary Partitions. Большее количество разделов можно создать по «матрёшечному» принципу, путём объявления одного из первичных разделов Extended Partition.

Расширенный раздел выступает в качестве контейнера, в который последовательно, как в матрёшку, вкладываются один логический раздел и ещё один расширенный раздел. Последний, в свою очередь, выступает контейнером второго уровня, и может включать ещё один логический раздел и следующий по очереди расширенный, — и так до бесконечности. Правда, аналогия с матрёшкой - не совсем строгая, потому что для пользователя все эти вложенные разделы видятся как равноправные части «головного» Extended-раздела. Да и на счёт бесконечности — тоже несколько преувеличено: на самом деле существует практический лимит для восприятия логических разделов, определяемый числом 63.

Разметка в стиле GPT (GUID Partition Table) — это новый формат таблицы разделов на носителях информации (традиционных винчестерах, SSD-накопителях, флэшках, SD-картах). Как явствует из названия, он основан на Globally Unique Identifier (GUID) — статистически уникальных 128-битных идентификаторах всего на свете, в том числе и носителей.

Таблица разделов GUID (далее для краткости я буду называть её просто GPT) существенно больше, нежели MBR.. Она занимает первые 34 блока (с нулевого по 33-й). Из них нулевой блок занимает всё тот же MBR — точнее, его защищённая (или защищающая? — protected) копия, предназначенная для программ, не понимающих GPT. Благодаря ему, скажем, утилита fdisk опознаёт винчестер с GPT как единый раздел неизвестного типа, но на самом деле работать с ним не может.

Следующий блок — это оглавление таблицы разделов, в котором предусмотрено место для 128 записей. Это, соответственно, максимальное число разделов при разметке в GPT-стиле. Наконец, остальные 32 блока предназначены для записи данных о разделах.