До этого времени, дел с менеждером томов LVM, я не имел, обходился простыми разделами и простыми дисками. По принципу "тик-так". Вышла новая Ubuntu - новый диск, т.к. сил обновлять старый нет. При двух дисках, для настольной системы, плавная миграция раз в полгода, а последнее время и раз в год. Т.к. любые манипуляции на рабочем диске, как то установка новой системы, даже в другой раздел, часто приводят (ли) к сбоям. Мне это не надо, поэтому новая система - новый диск (хорошо забытый старый).
Удивительно то, что нет у меня в доступном обозрении, дисков фирмы WD, все диски - Seagate (большая часть), один Samsung, один Hitachi. Хотя, может быть где-нибудь и завалялся "Западный цифровой".
Seagate-fun.
Надо будет исправить оплошность - повысить разнообразие экосистемы.
Отвлекся.
Главный вопрос
Возник вопрос(ы). Нужен ли мне LVM, что я смогу с ним сделать и не усложнит ли это мне восстановление информации, в случае отказов?
Дополнительные вопросы
Это вопросы, которые меня интересуют до того, как я погружусь в чтение руководств по LVM. Т.е. в этой теме - я чистый лист.
Сразу вопрос, можно ли существующие разделы с данными (по живому) объединить под командой LVM. Или надо их изначально туда включать чистыми и заполнять?
RAID потом LVM, или LVM а потом RAID - вот в чём вопрос
Т.к. были приобретены 2 диска, с прицелом на создание зеркального RAID. то и возник такой вопрос.
А нужен ли RAID-1, его достоинства и недостатки, в применении к моим задачам.
А как файлы хранятся на LVM? Дефрагментированы ли они?
Кое-что о разбиении диска
Раздел - мощное средство управиться с огромным количеством файлов, путем их разделения по разделам.
Что лучше - один большой том, с большой файловой иерархией, либо много мелких специализированных разделов.
Какие особенности вовлекаются в процесс выбора. Надежность файловой системы, сама файловая система, удобство работы с файлами, возможность и время восстановления.
Соображения о разбиении диска
Изначально, я планировал разбить каждый диск, на несколько десятков разделов, применяя GPT, для различного назначения, сделав часть из них зеркальными, часть просто разделами, часть системными, часть резервными.
Я также, планировал обеспечить загрузку диска в различных системах, таких как Linux, Mac OS X, Windows 8 исключительно с целью оперативного получения доступа к хранимым данным. То, что данные сейчас находятся на микросервере, это вель ещё не значит, что они там будут всегда. Хороший образ, иллюстрирующий идею, - цветок из кинофильма "Leon", который путешествует с главным героем во всех передрягах.
Теперь, к плану добавилась такие вещи, как LVM и RAID. И пришло время продумать всё тщательнее и обстоятельнее, переосмыслить. Ведь любое средство, надо грамотно применить и получить пользу.
LVM концепция - раскрывает множество возможностей по операциям с разделами, да вот выбрать какие нужны и будут полезны - сложно. Идея LVM должна отлежаться в мозгу, наладить связи.
Раздел - это обособление, свой участок, "свои погремушки" и своё собственное командование им.
Раздел - это грануляция, - уменьшение влияния изменений на целое - систему, совокупность данных и уже только это повышает надежность.
Простейшее разделение - система и данные. В систему вносятся изменения, она обновляется, данные при этом не затрагиваются. Поделим дальше, - выделим раздел для временных файлов, - они постоянно изменяются, а программные файлы редко, - уже выгода, особенно для ssd-дисков, с ограниченным ресурсом изменений. Можно пойти дальше, папку пользователя разбить на разделы, например конфигурационные данные приложений (файлы с точкой), отдельно почтовый раздел, документы, фото и видеоматериалы, а можно сделать разделы по годам, а когда накопиться много лишнего места на них, провести реорганизацию.
В идеале, надо выйти из мысленного ограничения - вся система на одном диске (разделе), и размазать систему по разным дискам и разделам. Чтобы потом не собрать.:-)
Маленькие разделы легко обслуживать стандартными средствами файловых систем, таких как восстановление и проверка, резервирование.
Маленький раздел, в случае потери может ограничить ущерб.
Можно определить приоритеты для резервирования и в критических ситуациях не растеряться, что хватать.
Разделы можно делать точно в размер CD, DVD, Blu-ray дисков для создания образов и их последующей записи.
Разделы можно создать точно в размер разделов компьютеров домашней сети, что облегчает резервирование данных и создание полных образов восстановления.
Создание раздела определенного согласованного размера, это выгодно. Ведь если подумать, то при двух разных разделах, операция перемещения данных, может включать и операцию преобразования раздела, а это опасная операция.
В эндшпиле, такое разделение системы может свестись к известной операции "copy-on-write", но на уровне разделов. Т.е. вначале скопировал раздел, а потом изменил в нём, а не в исходном. Как SSD поступает с данными, так и пользователь.
Что будет, если выйдет из строя файловая система пару-терабайтного диска с миллионом файлов? Сколько займет времени восстановление? Оно реально? Понадобятся ли (да) ещё диски для создания исходного образа отказавшего тома? Это кажется, что аккуратное обращение - гарантия, но это не так.
Пока единственным плюсом большого тома (проверено на личном опыте), я вижу то, что данные все находятся в известном мне месте, они тут все, и не надо гадать, что они где-то "рассованы" по разным местам.
Минусов правда больше. Большой том - обязательно raid-1 + резервный диск. Итого 3 диска. Иначе чувство не покидает.
С другой стороны, что будет с операционной системой, монтирующей в "угаре автомонтирования", несколько десятков разделов с разнообразными файловыми системами, внешний жесткий диск? Правда-правда, она отработает? Да?
Можно пойти по пути, - заранее разметить (благо GPT позволяет) нужное количество разделов. Почему заранее? Потому что, любые операции с разделами - опасны для данных и их лучше не делать, а лучше делать пока нет данных. Почему опасны? Потому что затрагивают целое, а на часть. А "ошибки оператора" постоянно случаются.
Можно пойти по пути, - использовать менеджера разделов (пока предполагается LVM, а там посмотрим) и динамически создавать разделы под нужные требования (надеюсь такое возможно).
Кстати, эти пути можно пройти и мысленно и выбрать более подходящий для реализации в текущий реальности.
И ещё раз, операции с разделами - опасны.
Данные должны быть зарезервированы. Поэтому, в старые времена, разделы делались в момент установки систем и не менялись. Однако сейчас, - не старые времена и доступны более гибкие средства, "по потере данных".
Но, главный приоритет - сохранение данных, продолжает оставаться.
Казалось бы, - как рекламируется, простая команда в Ubuntu apt-get dist-upgrade, а приносит столько несчастья. Да что upgrade, update обыкновенный. Думаю, примеры всем знакомы на личном опыте. Т.к. с желанием обновляться, пробовать новое, сложно совладать, то я просто выделяю отдельную систему (диск, раздел) для этих целей, которая, и тестирование обновлений может выполнить, и удовлетворить чувство.
Не трогаешь сервер, - полгода работает, начал обновление - жди плясок, - в счастливой части вероятности, иного - в другой половине.
И так, с любыми системами, в любые времена.
Как показало время, в домашней практике, лучше применять стабильные, редко изменяемые системы. Пусть они не оптимальны, устарелы, вышли из употребления, но работают, привычны, понимаемы. "Старый теплый свитер". И не перегибать палку с дискетами. Но настало время, рост объемов данных уже превысил возможности старого железа, например USB2.0, в части удобного обращения с данными. Простое копирование двух-терабайтного винчестера отнимает день. Пора переходить на новые скоростные технологии, благо они начали появляться на массовом рынке. В этом нам помогут такие вещи, как Thunderbolt, Infiniband, 10G Ethernet, USB3.0, Sata III и пр.
И ещё, т.к. в домашних условиях сложно применить корпоративные средства управления хранением, то важным факторов организации, как ни странно, является принтер. Он, позволяет напечатать твердую копию настроек системы, которые помогут в трудный момент. Он, позволяет распечатывать обложки дисков, списки дисков и разделов, липкие метки - всё то, что облегчает ручную организацию данных.
Небольшой учёт оборудования (ведение инвентаря), по таким параметрам, как дата приобретения, позволяет вовремя проводить обновление оборудования и не допускать отказов во второй опасный период, после окончания гарантии.
Бортовой журнал изменений - также упростит восстановление понимания некоторых вопросов, по прошествии времени.
Периодическая диагностика дисков по их smart аттрибутам и сохранения снимков состояния, позволит понять историю и направление изменений.
Всё это, увы, - ручные операции человека. Однако польза, от их наличия - перевешивает.
Можно это всё исключить, но тогда "стук блока головок", "звук пилы" - станут полезным личным опытом.
Как ни странно, но встроенная надежность оборудования, играет существенную роль в сохранности данных. Такие известные и доступные технологии, как память с коррекцией ошибок (ECC), SATA шлейфы с защелками, либо SATA корзины, регулируемое охлаждение, источники бесперебойного питания - снимут много головной боли. Пользу их можно понять двумя путями, на личном опыте и на чужом опыте.
Об онлайн-хранении
Любые сервисы онлайн-хранения, даже этот блог, подвержены одной чрезвычаайно неприятной особенности - Вы их не контролируете. Это как с ЖКХ - тоже сервис. Нравится сервис ЖКХ? Скоро прийдем к такому же, только в компьютерной области.
Стоит завязаться на онлайн-сервис, привыкнуть к нему, так сразу он даст о себе знать, покажет вторую сторону монеты.
Всё может превратиться, в один момент, в черепки. Примут закон - запретить кокретный сервис и приплыли - данные потерялись. Вопли, крики, слёзы. "Ктож знал, ктожзнал"?
А незачем отклоняться от первоначальной идеи Интернета. А поделом.
Доступность данных
Данные накопленные, но находящиеся в архивных файлах, таких как zip,rar, в образах iso, в закрытых образах, недоступны. А ведь они при определенном поисковом запросе вполне могут помочь, что-то прояснить.
Контроль доступа
Знание того, кто, когда и что запросил, добавил, удалил - чрезвычайно ценно.
Журнал доступа - хороший вариант.
LVM. Рекомендация 1
Т.к. для физического тома LVM, выделен специальный код раздела, то надо форматировать жесткий диск, разбивать на разделы и только потом, уже из разделов собирать придуманную конструкцию, будь то raid, lvm.
Иначе, если диск сырой, то Windows легко предложит его отформатировать и можно "случайно", а на самом деле, предсказуемо, нажать "Да".
Т.е. Диск должен быть размечен. Выбор сегодня - GPT.
GPT. Разметка дисков
Т.к. мы имеем дело с дисками, то примем следующее обозначения.
1 MiB - 1024 KiB - (1024x1024) bytes - используется в компьютерной технике.
1 MB - 1000 KB - 1000x1000 bytes - используется при указании емкости современных жестких дисков, blu-ray, карт-памяти. "Маркетинговые мегабайты".
Т.е. гибибайты, мибибайты, кибибайты - будем использовать, а мегабайты и килобайты - оставим на совести дисков и будем редко к ним прибегать.
GPT система, продолжает придерживаться выравнивания кратного 2, так что при указании размеров, только гибибайты, мибибайты и кибибайты.
Ну и ладно - прояснили.
Можно тренироваться с графической утилитой "Диски", но нам требуется точность разметки, а её обеспечивает утилита командной строки gdisk и калькулятор calc.
если она не установлена, а она не установлена в стандартной Ubuntu, то:
apt-get install gdisk
Размечать придется 2 диска, т.к. система ориентирована на уникальные GUID, то различия в дисках будут именно в этом - в уникальных идентификаторах разделов, т.к. они генерируются при создании.
Программа интерактивная, так что будем нажимать кнопки.
root@microserver:# gdisk /dev/sda
В данном случае, на микросервере, sda - диск в первой корзине, sdb - диск во второй корзине. Но надо чётко отслеживать - какой диск размечается, чтобы защитить ценное.
Есть тактическая особенность, которую приятно использовать - это то, что у жесткого диска, в начале (ближе к центру вращения), скорость доступа выше, выше линейная скорость. Т.е. первые разделы, всегда скоростные.
Ранее, при MBR, я использовал первый раздел под раздел подкачки (swap). Второй под систему, третий резервный, четвертый - домашняя папка.
Сейчас, при GPT, принцип сохраняется, просто увеличивается гибкость по разделам, их числу.
Нам полезны "пара-тройка" команд:
o create a new empty GUID partition table (GPT)
n add a new partition
t change a partition's type code
Итак, o - создание разметки GPT, n - добавление нового раздела, t - изменение типа раздела, если ошиблись при добавлении.
q quit without saving changes
b back up GPT data to a file
w write table to disk and exit
Для сохранения промежуточных версий GPT-разметки, удобно использовать команду b. Т.е. можно поиграться.
q - выход из программы, без сохранения на диск изменений.
Основная команда - добавление нового раздела - n. Т.к. я выбрал консольный путь, то придется указывать точные размеры разделов.
Вначале, пойдут системные разделы. Небольшой обзор разделов, можно найти в Википедии [см. Ресурсы п. 5].
Т.к. Linux - основная система, то её разделы пойдут первыми.
А самым первым пойдет системный раздел EFI (ESP).
Назначение ESP раздела подробно описано в спецификации UEFI. Применятся для хранения загрузчиков, драйверов системы UEFI, обновлений прошивки (firmware), efi-утилит.
Для нас, важен размер, формат и местоположение.
Компания Microsoft рекомендует делать системны раздел ESP - первым в таблице разделов.
Также Microsoft требует наличие сразу за ESP разделом, раздела MSR - Microsoft Reserved Partition, объемом 128MiB для дисков более 16GB.
Раздел MSR обязан быть на каждом диске. Размещаться он также может после OEM-разделов, которые следуют за ESP разделом.
Mac OS X также имеет специфические требования к разделу ESP [см. Ресурсы п.8]. Некоторые версии Ubuntu вообще могут удалить существующий ESP раздел. Разные установщики дистрибутивов Linux создают разные размеры ESP.
Формат системного раздела ESP - FAT32, FAT16. Windows предполагает - FAT32. На самом деле, формат определяется спецификацией UEFI и в данный момент выглядит как FAT32.
Выберем формат ESP - FAT32, как максимально совместимый с системами.
Размер. Mac OS X для больших дисков создает ESP раздел объемом 200МиБ.
Также, после каждого раздела создается 128 МиБ свободного места, за исключением ESP.
Таким образом, наиболее сложные ограничения накладывает Mac OS X и Windows. Им и будем следовать.
Также, перед установкой Ubuntu, диск должен быть размечен. Надеюсь, что встроенные утилиты других систем, не испортят всю задумку.
Можно было бы сделать разметку в Mac OSX, но её нет под рукой, поэтому Ubuntu.
И не использовать старые версии Ubuntu и пр. систем, на новом диске.
Итак, цифры: 200MiB - 209715200 байт (409600 секторов по 512 байт), 128MiB - 134217728 байт (262144 по 512 байт).
Можно создавать. Команда o, затем n.
Первый сектор первого раздела выровняем до 2048.Просто нажмем "Enter".
Последний сектор первого зададим так: +200MiB.
Код раздела укажем таким: ef00. Что соответствует ESP, а в терминологии программы gdisk - EFI System.
После выполним команду p и проверим правильность.
Command (? for help): p
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): много цифр
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860123501 sectors (2.7 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
Граница 2048 - это 1 MiB.
Создание OEM раздела, упоминаемого Microsoft, пропустим, т.к. неясен его GUID и размер.
Создадим MSR раздел
Если забыть создать MSR раздел, то Windows будет считать, что диск содержит ошибки и если их исправить, она пометит второй раздел как MSR, а если он был загрузочный раздел другой системы, то понятно - сбой загрузки.
Вторым разделом пойдет раздел MSR. Его делаем без промежутка в 128MiB.
Требуемый размер: 128MiB.
Код раздела:
На этом этапе можно выполнить запись на диск, командой w, а потом перезапустить утилиту.
Вывод будет следующий:
GPT fdisk (gdisk) version 0.8.5
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Total free space is 5859861357 sectors (2.7 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
Базовая структура GPT диска создана.
Остается один вопрос, 128 MiB чистого места оставлять только после разделов Apple, либо после всех разделов? Как-то не могу прояснить этот вопрос, поэтому буду исходит из более строго ограничения - после всех.
В пустоту, а может и в пользу, уйдет около ~ 3GB.
Делается, это так, +128MiB при указании начального сектора любого последующего раздела.
Разделы подкачки (виртуальной памяти на диске)
Раздел подкачки - должен быть кратным степени двойки, совпадать или превышать объем оперативной памяти, желательно, но не обязательно кратно. Можно сделать несколько разделов подкачки. Тут также есть свои рекомендации у разных операционных систем. Я поступлю проще, зарезервирую объем.
Раздел подкачки используется также в режиме hybernation, когда на него сохраняется образ памяти.
Код раздела подкачки (swap) Linux: 8200
Задаем первый сектор, +128MiB, (нажмем ввод), второй сектор: +8GiB.
Итого (команда p - печать таблицы разделов):
Третьим пойдет также раздел подкачки, 8 GiB,также с отступом в 128MiB.
Код раздела подкачки (swap) Linux: 8200
Задаем первый сектор: +128MiB, второй сектор: +8GiB.
Итого (команда p - печать таблицы разделов):
Total free space is 5826306925 sectors (2.7 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
Видно, что стартовый и конечный сектора 3 и 2 разделов разнесены.
Подтверждение вычисляется так: Стартовый сектор - 1 - Конечный сектор предыдущего раздела. Умножаем на размер сектора (512 байт, в данном случае), делим на 1024 и еще раз на 1024. Получаем число 128. 128 MiB.
Записываем структуру на диск. нажимаем w.
Процедура ясна, можно приступать к нарезке.
GPT. Система Linux. Система Mac OS X. Система Windows.
Т.к. диски будут экслуатироваться на сервере, то разделы операционных систем не будут использоваться, под ОС, по крайней мере, в настоящее время. Но они будут.
Первой пойдет система Linux, в начале диска, она будет самая быстрая.
Для неё выделим раздел корневой системы (/), раздел домашних папок (/home), резервный раздел корневой системы, резервный раздел домашних папок. Т.е. при желании, на диск можно будет установить 2 системы, параллельно. Хотелось бы 3, но не надо.
Т.к. разделы в резерве, то их размер сделаем хитрым, кратным размеру однослойного Blu-ray диска.
Точный размер Blu-ray диска, способ его получения, можно посмотреть в заметке: Blu-ray диски в Ubuntu.
Для имеющихся у меня дисков Verbatim - размер 23610MiB.
Незабудим про границы в 128MiB.
Итого 4 раздела по ~25GB - ~ 100 GB. Как раз один диск BD-RE XL = 100GB.
Задаем первый сектор: +128MiB, второй сектор: +23610MiB.
И так повторяем 4 раза.
Итого (команда p - печать таблицы разделов):
Total free space is 5632893805 sectors (2.6 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
5 35014656 83367935 23.1 GiB 8300 Linux filesystem
6 83630080 131983359 23.1 GiB 8300 Linux filesystem
7 132245504 180598783 23.1 GiB 8300 Linux filesystem
8 180860928 229214207 23.1 GiB 8300 Linux filesystem
В принципе, таких небольших разделов достаточно, т.к. Linux позволяет по мере надобности подключать точки монтирования и пр. А у меня задача, сделать более мелкие разделы для системы, а данные положить в свои отдельные разделы.
Сохраняемся - команда w. Перзапускаем утилиту.
Система Mac OS X следующая (потенциально следующая).
Для системы Mac OS X нужны следующие разделы: один системный HFS+.
На нём всё, и система. и данные локальных пользователей. Возможно понадобиться еще и раздел Apple RAID. Т.к. Система Mac OS X также обновляется, то понадобиться второй комплект разделов, чтобы следовать процедуре "тик-так".
Код раздела для установки Mac OS X: AF00 Apple HFS/HFS+
Система Windows.
Для системы Windows (7, 8 версии) требуется по отдельному разделу. Т.к. разделы одиночные, то и размер должен быть большим. Однако, существует возможность вынести папку Users на отдельный раздел.
По опыту, для системы Windows 7, будет достаточно около 60 GiB для системы (много программ), без папок пользователя. Также может понадобиться раздел для создания образа системы, а возможно и раздел для резервирования, встроенным средством архивации и восстановления. Т.е. 3 windows-раздела, для одной системы. 2 windows системы - 6 разделов.
Кстати, что ждёт пользователей, займись они разделами в среде Windows, можно прочитать в статье "6 ошибок людей с маленькими разделами"[Ресурсы п.9].
В принципе, да, в Windows 7, я практически следую таким рекомендациям.
Однако, данные нужны в разных системах, и их вынос в отдельные разделы помогает держать их под контролем. Да и объем в 2 TiB, хранить в домашней папке рабочей системы - небезопасно. Очень часто, большая вложенность папок превышает лимиты на длину имени файлов, что приводит к невозможности скопировать такой файл.
Операция резервирования при 2TiB в одной папке, вполне может не закончиться.
К разметке, можно подходить с позиций последующего восстановления данных, т.к. поиск разделов на диске, с затертым оглавлением, вполне по силам утилитам, таким как testdisk. Да и архивный файл GPT разметки, может помощь. А вот с одной огромной файловой системой, такой уверености нет и не будет.
Недостаток обычного разделения диска (например GPT) - невозможность стандартными средствами изменить, объединить, перераспределить разделы, без потери данных.
В принципе, 2 раздела по 100 GB (точно 94440MiB), может хватить, для двух систем, которые редко используется, и в них данные не накапливаются.
Опять же, разделы эти потенциальные. + 2 раздела для полного резервирования, такого же объема.
А выравнивание по объему с диском BD-RE XL 100 GB, даст возможность простого резервирования.
И ещё, т.к. иногда может потребоваться создание образа BD-R диска, а они на сегодняшний момент достигают в размере 128 GB, то и раздел для них должен быть больше - файл то, надо на разделе создавать и хранить Это можно предусмотреть в конце диска.
Также можно потом, в конце диска, предусмотреть раздел для икрементных архивов.
Т.к. ближе к центру диска - быстрее, то первые системы (Mac OS X и Windows) будут первыми двумя следующими разделами.Затем небольшой раздел обмена (см. далее). Затем блок вторых систем, затем блок резервных разделов.
Total free space is 4569121645 sectors (2.1 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
5 35014656 83367935 23.1 GiB 8300 Linux filesystem
6 83630080 131983359 23.1 GiB 8300 Linux filesystem
7 132245504 180598783 23.1 GiB 8300 Linux filesystem
8 180860928 229214207 23.1 GiB 8300 Linux filesystem
9 229476352 422889471 92.2 GiB AF00 Apple HFS/HFS+
10 423151616 616564735 92.2 GiB 0700 Microsoft basic data
11 616826880 665180159 23.1 GiB 0700 Microsoft basic data
12 665442304 858855423 92.2 GiB AF00 Apple HFS/HFS+
13 859117568 1052530687 92.2 GiB 0700 Microsoft basic data
14 1052792832 1246205951 92.2 GiB AF00 Apple HFS/HFS+
15 1246468096 1294821375 23.1 GiB 0700 Microsoft basic data
Раздел №11 - малый транзитный раздел. Будет отформатирован, скорее всего в UDF, возможно из-под Windows, а пока из под Linux.
Разделы №14 и №15 - разделы для полного резервирования систем Mac OSX и Windows, соответственно.
Графическая утилита "Диски", превращается в длинное окно. Его даже не удалось, сфотографировать, по Alt+PrtScn :-) Баг однако. А нет, 2 бага однако, в двух программах.
 |
| 14 разделов на диске GPT |
Также, можно заметить из таблицы, что стартовые секторы - четные, т.е. разделы выровнены. А конечные - нечетные.
GPT. Разделы обмена данными - транзитные разделы
Основное требование - файловая система доступная на чтение/запись из любой системы, на этом диске.
Сделаем один большой раздел обмена данными между операционными системи, по размеру превышающий размер Blu-ray BD-R XL 128 GB. Чтобы его можно было перенести. Во что его отформатировать?
Сделаем небольшой раздел, для обмена данными, не более 30 GB.
Рассматриваются форматы Fat32, exFAT, UDF предварительно.
Выбран UDF. Уже сделан, под №11.
GPT. Эксперимент с удалением раздела на живом диске
Был отформатирован раздел №11 в файловую систему UDF. Далее был удален раздел №2 (swap). Потом воссоздан, по исходным размерам.
Данные на разделе №11 сохранились.
GPT. Эксперимент с увеличением раздела, за счёт соседнего
Не проводился.
GPT. Ещё разделов, для виртуальных машин
С системными разделами почти закончили, создадим пару разделов для виртуальных машин. Да, по 23610MiB.
Тип этих разделов: 8301 Linux reserved
Ещё нет разделов объемом с двуслойный диск BD-R.
Предположим 2 слоя - (23610*2) = 47220 MiB. У меня пока нет 2-х слойного диска, чтобы проверить. Как прибудет из Японии, так сразу же.
Итого, на данном этапе 18 разделов:
Total free space is 4375708525 sectors (2.0 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
5 35014656 83367935 23.1 GiB 8300 Linux filesystem
6 83630080 131983359 23.1 GiB 8300 Linux filesystem
7 132245504 180598783 23.1 GiB 8300 Linux filesystem
8 180860928 229214207 23.1 GiB 8300 Linux filesystem
9 229476352 422889471 92.2 GiB AF00 Apple HFS/HFS+
10 423151616 616564735 92.2 GiB 0700 Microsoft basic data
11 616826880 665180159 23.1 GiB 0700 Microsoft basic data
12 665442304 858855423 92.2 GiB AF00 Apple HFS/HFS+
13 859117568 1052530687 92.2 GiB 0700 Microsoft basic data
14 1052792832 1246205951 92.2 GiB AF00 Apple HFS/HFS+
15 1246468096 1294821375 23.1 GiB 0700 Microsoft basic data
16 1295083520 1343436799 23.1 GiB 8301 Linux reserved
17 1343698944 1392052223 23.1 GiB 8301 Linux reserved
18 1392314368 1489020927 46.1 GiB 0700 Microsoft basic data
Однако, постепенно чувствуется ограничение маленьких разделов - невозможность работы с огромными файлами.
В принципе, я добрался до создания LVM разделов. Но добавлю ещё, пару интересностей.
GPT. Раздел для хранения зеркала текущей системы
Локальный репозиторий (зеркало) текущей установленной системы, может достигать 150 ГБ и размер растёт. Т.е. раздел для таких данных, используемых только в Linux, имеет смысл поместить в LVM.
Т.к. апгрейд системы, случается ежегодно, то старое зеркало вполне может мигрировать на другие разделы (другие диски). Такие задачи, хорошо укладываются в логику LVM.
Однако и тут можно поработать надо размерами данных, разделить их на бинарные и исходные коды и разнести по разным разделам.
GPT. Раздел для хранения текущей версии ядра Linux
Это вообще, может показаться странным. Однако и на это, есть свои соображения.
Исходные коды ядра сейчас в сжатом виде имеют размер ~ 70-100 MiB.
Т.е. для хранения можно сделать небольшой размер раздела. Как раз размер CD подойдет.
Этот раздел - для души, чтобы не потерять вечную ценность.
Размер у диска CD-R в наличии - 736960512 байт. Его и зададим, но в KiB.
719688KiB.
Код у раздела: 8301 Linux reserverd. Потом найду и изменю на более подходящий для файловой системы ISO9660.
А вот файловую систему, сделаю ISO9660. И с помощью волшебной утилиты xorriso, буду записывать файлы на раздел, сразу в формате ISO9660. Это восхитительная возможность.
# xorriso -dev stdio:/dev/sda19 -blank
А это запись произвольных файлов:
# xorriso -dev stdio:/dev/sda19 -add ./*.log
После этого, раздел можно примонтировать в системе, как обычный CDROM, правда только на чтение.
Существуют опции для задания метки тома, и пр. меток относящихся к формату ISO9660.
# xorriso -dev stdio:/dev/sda19 -volid 1
Стандарт ECMA-119 разрешает только ASCII символы из набора [A-Z0-9_].: "VOL_123". Всего 32 символа.
# xorriso -dev stdio:/dev/sda19 -joliet on -blank
Пополнять его можно автоматически по расписанию.
"Сбросить" раздел можно в файл iso-образа, а потом записать, либо сразу на носитель CD-R в дисководе.
# dd if=/dev/sda19 of=~/sda19-cdr.iso
1439376+0 записей считано
1439376+0 записей написано
скопировано 736960512 байт (737 MB), 24,7701 c, 29,8 MB/c
Видно, что размер образа раздела - совпадает с заданным, при его разметке. И внутри ISO9660.
Скорость небольшая, потому что копируется на usb-ssd диск.
Полученный файл можно примонтировать и просмотреть, всё ли корректно. Особенно имена, даты, метки.
Ну и для полного улёта, такое же счастье доступно для DVD-R. Что даёт ~ 4.7 GB. 4700372992 байт, 4590208KiB.
Недостатком, а порой и достоинством, мне кажется, является огромное количество опций и ограничений файловой системы ISO9660, без указания которых - будет простейшая файловая система ISO9660, с ограничениями в именах файлов, метке и пр.
В помощь:
# man xorriso
Пока неизвестно, как раздел такого типа поведет себя в других операционных системах. В Linux, на удивление, всё работает, даже утилита "Диски" показывает, что раздел содержит iso9660. А вот с типом раздела непонятно.
Итого 20 разделов:
Total free space is 4365088733 sectors (2.0 TiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
5 35014656 83367935 23.1 GiB 8300 Linux filesystem
6 83630080 131983359 23.1 GiB 8300 Linux filesystem
7 132245504 180598783 23.1 GiB 8300 Linux filesystem
8 180860928 229214207 23.1 GiB 8300 Linux filesystem
9 229476352 422889471 92.2 GiB AF00 Apple HFS/HFS+
10 423151616 616564735 92.2 GiB 0700 Microsoft basic data
11 616826880 665180159 23.1 GiB 0700 Microsoft basic data
12 665442304 858855423 92.2 GiB AF00 Apple HFS/HFS+
13 859117568 1052530687 92.2 GiB 0700 Microsoft basic data
14 1052792832 1246205951 92.2 GiB AF00 Apple HFS/HFS+
15 1246468096 1294821375 23.1 GiB 0700 Microsoft basic data
16 1295083520 1343436799 23.1 GiB 8301 Linux reserved
17 1343698944 1392052223 23.1 GiB 8301 Linux reserved
18 1392314368 1489020927 46.1 GiB 0700 Microsoft basic data
19 1489283072 1490722447 702.8 MiB 8301 Linux reserved
20 1490984960 1500165375 4.4 GiB 8301 Linux reserved
Разделы №5-6, №9, №10 - первые системы Linux, Mac OSX, Windows7.
Разделы №7-8, №12, №13 - вторые системы Linux, Mac OSX, Windows7 ( в рамках процедуры обновления "тик-так").
Разделы №11 - раздел для обмена небольшими данными.
Раздел №20 - можно использовать для обмена данными побольше.
Раздел №14, №15 - разделы для полного резервирования дисков систем MacOSX и Windows (байт-в--байт).
GPT. Как хранить пользовательские данные
Как лучше, один раздел LVM ~ 1.5 TB или несколько меньших разделов, в качестве физических томов?
В пользу одного раздела, то, что на нижнем уровне (уровень таблицы GPT), будет четко понятно - один раздел LVM, и что внутри, надо смотреть утилитами LVM. Однако, всё простраство раздела LVM, будет доступно только в Linux и недоступно в других системах.
Да, у Linux - LVM и RAID разделы, у Apple - Apple RAID, у Windows Windows LDM data и динамические диски. Т.е. те разделы, которые предназначены для хранения данных, надёжного хранения, недоступны из других систем. И если система отказала, ну Вы поняли.
Linux является основной системой и данные будут храниться в ней, но данные для домашних машин под Windows.
Может, пока не поздно, сделать раздел для хранения данных, доступный и в Windows, например 500 ГБ отформатированных NTFS? Или весь свободный объем в NTFS. И пусть линукс мучается с NTFS.
Будет прекрасно, вынул диск из сервера, подключил к настольному компьютеру и получил доступ к данным. Сунул обратно - доступ по самбе. И не обращать внимание на производительность. А?
Такой вариант мне нравиться и я так сделаю, на двух других дисках, меньшего объема.
Тут есть конечно риск, при всех этих движениях, случайно уронить диск, зацепить или физически повредить, или электрически повредить. Т.е. физические манипуляции с дисками заполненными хранимыми данными, не приветствуются.
Кстати, т.к. пока есть 2 незаполненных диска, можно попробовать, на одном диске один подход, на другом - другой. И выбрать подходящий. А варианты разметки сохранять в файлах, и загружать, и экспериментировать.
Возможно, стоит сделать размер LVM тома кратный размеру однослойного blu-ray диска.
То что, будет большой раздел LVM, я уже определился. Т.к. намного проще манипулировать логическими томами, чем напрямую в GPT.
Также должен существовать и большой раздел Linux (пусть и в LVM), размер которого можно изменять динамически. Т.к. файлы могут быть большими.
Посмотрим, какие ограничения возникнут при использовании NTFS в Linux. Первое и главное - непонятен уровень поддержки всех возможностей NTFS. Не получится ли так, что запись из под Linux работает, а в Windows - разрушенная файловая система или с ошибками.
Сделаю разделы LVM (будущие 2 физических тома), каждый по 1 TiB неформатированной емкости. Тибибайт - места достаточно, даже для полного образа Терабайтного диска. Выясниться точно, после форматирования.
Total free space is 70121437 sectors (33.4 GiB)
Number Start (sector) End (sector) Size Code Name
1 2048 411647 200.0 MiB EF00 EFI System
2 411648 673791 128.0 MiB 0C01 Microsoft reserved
3 935936 17713151 8.0 GiB 8200 Linux swap
4 17975296 34752511 8.0 GiB 8200 Linux swap
5 35014656 83367935 23.1 GiB 8300 Linux filesystem
6 83630080 131983359 23.1 GiB 8300 Linux filesystem
7 132245504 180598783 23.1 GiB 8300 Linux filesystem
8 180860928 229214207 23.1 GiB 8300 Linux filesystem
9 229476352 422889471 92.2 GiB AF00 Apple HFS/HFS+
10 423151616 616564735 92.2 GiB 0700 Microsoft basic data
11 616826880 665180159 23.1 GiB 0700 Microsoft basic data
12 665442304 858855423 92.2 GiB AF00 Apple HFS/HFS+
13 859117568 1052530687 92.2 GiB 0700 Microsoft basic data
14 1052792832 1246205951 92.2 GiB AF00 Apple HFS/HFS+
15 1246468096 1294821375 23.1 GiB 0700 Microsoft basic data
16 1295083520 1343436799 23.1 GiB 8301 Linux reserved
17 1343698944 1392052223 23.1 GiB 8301 Linux reserved
18 1392314368 1489020927 46.1 GiB 0700 Microsoft basic data
19 1489283072 1490722447 702.8 MiB 8301 Linux reserved
20 1490984960 1500165375 4.4 GiB 8301 Linux reserved
21 1500428288 3647911935 1024.0 GiB 8E00 Linux LVM
22 3648174080 5795657727 1024.0 GiB 8E00 Linux LVM
Остается ~ 33GiB, которые можно потратить на эксперименты с HPA и пр.
GPT. Перенос сформированной таблицы GPT на другой диск
Диск /dev/sdb, размечать в ручную не надо. Есть встроенное средство "репликации". Доступно из расширенного меню, вызываемого по команде x.
Итак,
# gdisk /dev/sda
Вводим x - расширенная функциональность.
Затем выбираем команду r - репликация.
вводим диск: /dev/sdb
Выходим из программы.
# gdisk /dev/sdb
Вводим x - расширенная функциональность gdisk
Затем набираем команду f. Рандомизация GUID. Это создаст на этом диске, разделы с уникальными (это требование GPT) GUID. А структура GPT Таблицы и GUID разделов - всё сохраниться.
Набираем w - запись изменений таблицы на диск.
Для проверки, можно использовать команду i, она печатает подробную информацию о разделе и сравнить GUID раздела двух дисков - они должны различаться.
Всё.
Два диска /dev/sda и /dev/sdb - размечены и готовы.
GPT. Сохранение таблицы разделов. Распечатка твёрдой копии
Что надо сделать обязательно, это воспользоваться командой b - backup, для резервирования GPT разметки дисков /dev/sda /dev/sdb
Полученные файлы сохранить на CD/DVD.
Далее, таблицу надо распечатать, по каждому диску и сохранить в папке конфигураций (обычной канцелярской папке).
Т.к. в системе настроен сетевой принтер, то можно отправить на принтер вывод команд:
# pvdisplay | lpr
# vgdisplay | lpr
# lvdisplay | lpr
Эта информация, очень поможет при восстановлении данных, в случае программных потерь GPT разметки, случайного форматирования и пр.
Даже, при диске выглядящим как "сырой","неформатированный", возможно будет монтировать разделы, просто по их смещениям.
При обращении с разделами, главное, не совершить "ошибки оператора".
GPT. GRUB2 BIOS/GPT boot
У GRUB2 существует хитрая возможность загрузки на компьютере с BIOS, с GPT диском. Но, данная возможность мало совместима с другими операционными системами.
Для GRUB2 создается специальный раздел BIOS Boot partition, в специальном месте.
Нетривиальная настройка, поэтому как-нибудь потом.
LVM. Инсталляция пакетов
LVM будет использовать последней, второй версии.
# apt-get install lvm2
LVM. Оформление тибибайтных разделов в качестве физических томов
Для первого диска: /dev/sda
# pvcreate /dev/sda21
Writing physical volume data to disk "/dev/sda21"
Physical volume "/dev/sda21" successfully created
# pvcreate /dev/sda22
Writing physical volume data to disk "/dev/sda22"
Physical volume "/dev/sda22" successfully created
successfully - успешно
Для второго диска: /dev/sdb
# pvcreate /dev/sdb21
# pvcreate /dev/sdb22
Для просмотра списка физических томов:
# pvdisplay
"/dev/sda21" is a new physical volume of "1,00 TiB"
--- NEW Physical volume ---
PV Name /dev/sda21
VG Name
PV Size 1,00 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Здесь будет GUID физического тома
"/dev/sda22" is a new physical volume of "1,00 TiB"
--- NEW Physical volume ---
PV Name /dev/sda22
VG Name
PV Size 1,00 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Здесь будет GUID физического тома
"/dev/sdb21" is a new physical volume of "1,00 TiB"
--- NEW Physical volume ---
PV Name /dev/sdb21
VG Name
PV Size 1,00 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Здесь будет GUID физического тома
"/dev/sdb22" is a new physical volume of "1,00 TiB"
--- NEW Physical volume ---
PV Name /dev/sdb22
VG Name
PV Size 1,00 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Здесь будет GUID физического тома
LVM. Включение физических томов (разделов) в группу томов
Группа томов (volume group - VG).
Как лучше, объединить физические тома (быв. разделы) одного диска в одну группу, а другого в другую.
Или, в одну группу объединить разделы (/dev/sda21 и /dev/sdb21), а во вторую (/dev/sda22 и /dev/sdb22).
Или, все 4 физических тома в одну группу? И тогда, это аналог JBOD, одного большого небезопасного 4 тибибайтного пространства. Вполне может возникнуть и такая потребность.
Или "крест-на-крест".
Воспользуюсь первым вариантом, т.к. расширение идет, за счет физического тома группы, т.е. за счёт раздела на том же диске.
# vgcreate microserver-vg-one /dev/sda21 /dev/sda22
# vgcreate microserver-vg-two /dev/sdb21 /dev/sdb22
Для просмотра существующих групп томов:
# vgdisplay
--- Volume group ---
VG Name microserver-vg-two
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 2,00 TiB
PE Size 4,00 MiB
Total PE 524286
Alloc PE / Size 0 / 0
Free PE / Size 524286 / 2,00 TiB
VG UUID Здесь GUID группы томов
--- Volume group ---
VG Name microserver-vg-one
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 2
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 2,00 TiB
PE Size 4,00 MiB
Total PE 524286
Alloc PE / Size 0 / 0
Free PE / Size 524286 / 2,00 TiB
VG UUID Здесь GUID группы томов
LVM. Создание логических томов
Логический том будет выглядеть обычным блочным устройством, которое можно форматировать в любую файловую систему.
Создаётся, логический том, командой lvcreate.
Обязательно указываются опции размера и группы томов.
# lvcreate -L 500GiB microserver-vg-one
# lvcreate -L 500GiB microserver-vg-two
Можно еще опцию -n, для задания имени логического тома указать.
С учётом того, что служебная информация, уменьшит результирующий объем.
Если бы знать точно, размер служебной информации, чтобы получить чистое форматированное пространство объемом 500GiB.
# lvdisplay
--- Logical volume ---
LV Path /dev/microserver-vg-two/lvol0
LV Name lvol0
VG Name microserver-vg-two
LV UUID stGh15-9r1u-5hUQ-0c3q-fIVm-aVDk-cSJmsE
LV Write Access read/write
LV Creation host, time ubuntu, 2012-10-24 16:00:00 +0400
LV Status available
# open 0
LV Size 500,00 GiB
Current LE 128000
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:1
--- Logical volume ---
LV Path /dev/microserver-vg-one/lvol0
LV Name lvol0
VG Name microserver-vg-one
LV UUID dStTWg-YzsT-vuhX-oQpO-KQG2-9HAy-kL71Kn
LV Write Access read/write
LV Creation host, time ubuntu, 2012-10-24 15:59:53 +0400
LV Status available
# open 0
LV Size 500,00 GiB
Current LE 128000
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0
Из простых операций с LVM всё.
LVM. Экспорт/Импорт
Да, ещё. Т.к. тома создавались под графической операционной системой, то прежде чем их использовать на микросервере, надо их отключить от этой системы (деактивировать) и потом подключить в микросервере (активировать).
Вот уже и возникло, серьёзное ограничение доступности данных. А ну как, система незагружается, как тогда деактивировать тома?
И на этот вопрос, ответ: надо активировать группу томов при загрузке, и деактивировать при выключении.
Деактивация при выключении vgchange -an
Активация при загрузке: vgchange -ay
Отмонтируем файловые системы, расположенные на логических томах, которые примонтированы:
Используется команда: umount
# vgchange -an microserver-vg-one
# vgchange -an microserver-vg-two
После загрузки микросервера
Можно посмотреть видны ли часть LVM:
root@microserver:# vgscan
root@microserver:# vgdisplay
root@microserver:# vgchange -ay
Отформатировать логические тома:
# mkfs.ext4 /dev/microserver-vg-one/lvol0
# mkfs.ext4 /dev/microserver-vg-two/lvol0
Примонтировать и использовать:
# mkdir /mnt/disk500GiB-1 /mnt/disk500GiB-2
Тестовое монтирование:
# mount -t ext4 /dev/microserver-vg-one/lvol0 /mnt/disk500GiB-1
# mount -t ext4 /dev/microserver-vg-two/lvol0 /mnt/disk500GiB-2
Не забыть про права пользователей, для доступа новой системе.
LVM. Возможности по работе с логическими томами
Изменение размера
Изменение размера логического тома. Состоит из двух частей - изменение размера логического тома LVM, за счет места в группе томов и изменение размера файловой системы.
Файловые системы ext3, ext4 поддерживает увеличение раздела "на лету", без демонтирования.
# man resize2fs
Самый больной вопрос, что будет с пользовательскими данными, при изменении размеров?
LVM. Резервирование данных с задержкой
Есть интересная идея, резервировать логический том LVM, с некоторой задержкой по времени. Длительность задержки - это параметр, его можно настроить вплоть до недели, месяца.
Основная польза - это нераспространение (задержка распространения) негативных изменений на резервную копию, чем страдают все "зеркала". Это, даёт потенциальную возможность оперативного предотвращения, при наличии соответствующих знаний и плана восстановления, а также вовремя замеченных негативных изменений. А можно "прохлопать".
LVM. Снимки состояния
Снимки состояния, "снапшоты" - очень полезная вещь, для резервирования постоянно изменяющихся данных.
Снижает производительность "на запись".
GPT. HPA - Host protected area
Это ещё одна интересная возможность современных технологий жестких дисков. Создание на диск специальной области, недоступной для разметки. Просто место.
Продолжение будет в Части II.
Ресурсы
1. http://xgu.ru/wiki/LVM
2. Управление логическими томами. http://www.ibm.com/developerworks/ru/library/l-lvm2/
3. http://xgu.ru/wiki/raid
4. Параметры влияющие на производительность программного raid. http://romanrm.ru/mdadm-raid
5. Таблица разделов GUID. http://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID
6. EFI system partition. http://en.wikipedia.org/wiki/EFI_System_partition
7. Windows & GPT FAQ. http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx
8. Secrets GPT. http://developer.apple.com/library/mac/#technotes/tn2166/_index.html
9. 6 ошибок людей с маленькими разделами. http://www.outsidethebox.ms/13005/
10. MSR - Microsoft Reserved partition. http://en.wikipedia.org/wiki/Microsoft_Reserved_Partition
11. Выпуски NTFS-3G. http://www.tuxera.com/community/release-history/
12. Область (раздел) HPA. http://en.wikipedia.org/wiki/Host_Protected_Area
13. Подсистема хранения данных в ОС Linux. LVM. http://www.ibm.com/developerworks/ru/edu/os_architecture_course3/section13.html
Комментариев нет:
Отправить комментарий