Алексей Федорчук
По прежним временам вспоминается, что была в KDE утилита, аналогичная GParted из Gtk-based систем, то есть графическая морда к консольной утилите parted. Однако ни в Maui, ни в Neon’е её не обнаружилось, а точное имя её я забыл. Тем не менее, с помощью apt search имя её выяснилось — partitionmanager, а на русский его, как выяснилось после установки, перевели как Диспетчер разделов для KDE. Под ним эта утилита и фигурирует в секцииСистема главного меню. И, будучи оттуда вызванной, после ввода пароля она выглядит следующим образом:
Доступные действия были более или менее ясны из подписей на инструментальной панели (которая в режим показа пиктограмм, вопреки контекстному меню по ПКМ, не переключается) и из просмотра главного меню. Однако разметка диска — дело ответственное, и прежде всего я решил ознакомиться с настройками программы. Они оказались не богатыми, и в основном сводятся к определению режима выравнивания и файловой системы по умолчанию (где я ничего менять не стал):
А из раздела Цвета файловых систем следовало, что таковые можно задать для абсолютно всех файловых систем, поддерживаемых Linux’ом, включая ZFS:
Не надо быть Шэ Холмсом, чтобы догадаться: все файловые системы, которым можно поменять цвет, должны поддерживаться диспетчером разделов, по крайней мере теоретически. И действительно, если зайти в меню Вид – Поддержка файловых систем, то в предагаемом списке все они фигурируют:
Причём сопровождаются списком пакетов, обеспечивающим для каждой необходимый инструментарий:
Правда, из этого списка становится очевидным, что поддержка многих файловых систем этого списка — по умолчанию действительно чисто теоретическая. Например, для работы ZFS требуется не только установить соответствующий инструментарий, но и собрать и загрузить модули ядра, чего штатно ни в Neon’е, ни в Maui нет. Тем не менее, и в таком виде это надо считать плюсом диспетчера разделов: в GParted, например, работа с ZFS невозможна даже при выполнении указанных условий, он её просто в упор не видит.
Однако разборки с ZFS я отложил на потом, а пока занялся более обыденными делами. Например, получением информации о дисках и разделах через пункт Свойства контекстного меню по ПКМ на тех или других, соответственно.
Информация о дисковых устройства выводится в следующем виде:
Если нажать здесь кнопку Дополнительно, можно получить резулльтаты диагностики SMART в деталях:
Сведения о разделе выглядят таким образом:
Работа с «чистым» диском начинается часто с создания на нём таблицы разделов. Это делается через меню: Устройства –> Создать таблицу разделов, где на выбор предлагается две схемы — GPT или MS-DOS:
В отличие от GPArted’а, здесь новая таблица разделов не создаётся сразу же — требуется пройти в меню Правка –> Применить, и подтвердить серьёзность своих намерений:
И это очень существенный плюс KDE’шного диспетчера разделов, хоть как-то страхующий от непоправимых ошибок. Если же намерения действительно серьёзны, то после завершения операции выводится сообщение о её успехе:
Что отражается в появлении неразмеченного дискового пространства на подопытном носителе:
Что обычно делают с неразмеченным дисковым пространством? Правильно, разбивают его на разделы, или размечают как единый раздел, например, так:
Здесь всё понятно без комментариев. Разве что стоит добавить только, что здесь в списке файловых систем будут присутствовать только реально доступные, то есть для которых установлены пакеты поддержки:
А кнопка Дополнительно выведет начальный и конечный «сектора» будущего раздела:
И при создании разделов внесённые изменения не будут претворены в жизнь сразу, а потребуют подтверждения — тем же самым образом, что и при создании таблицы разделов. А по завершении процедуры выводится отчёт о проделанной работе:
Действия по изменению раздела и его перемещению выполняются очевидным образом, и на них я останавливаться не буду. Столь же тривиально удаление раздела. А уничтожение оного, насколько я понял, отличается тем, что при этом не только удаляется запись из таблицы разделов, но и содержимое перезаписывается тем, что определено в настройках (по умолчанию — случайными данными). И потому процесс этот занимает некоторое время.
Диспетчер разделов KDE позволяет также создавать их резервные копии. И пройти мимо этой возможности я не мог, решив (с пользой для дела) создать копию раздела с «системой-маткой» для своих сборок Cintu 16.04:
Перед началом процедуры нужно задать путь и имя целевого файла, а затем опять дать своё согласие на её выполнение:
Процедура эта может быть весьма длительной, но в конце концов закончится сообщением о её успехе:
Разумеется, создание резервной копии подразумевает, что ей можно воспользоваться для восстановления системы на другом носителе. Что я и попытался проделать. И поначалу всё шло хорошо. Я выбрал свою подопытную флешку в качестве целевого носителя (благо, моя подопытная флешка была равна по объёму исходному разделу):
Выразил свою готовность потерять на ней все данные (которых там и не было):
И ещё раз подтвердил, что я действительно хочу восстановить раздел из файла на выбранное устройство:
И процесс пошёл:
Шёл он долго — более часа, и обещал продолжаться ещё столько же. Но обещания этого не выполнил, потому что вдруг прекратился с сообщением, что в ходе восстановления произошёл сбой. Причины которого я не понял: размер исходного раздела был почти на два гигабайта меньше, чем целевого устройства (27,95 ГБ против 29,81 ГБ, соответственно), так что о нехватке места речи быть не могло. Да и на целевом устройстве файловая система была развёрнута полностью, и в том же объёме, что на исходнике:
Так что, возможно, всё и завершилось благополучно, но проверять этого я пок ане стал. Решив вернуться в вопросу о бэкапе и восстановлении из него, когда такая задача встанет реально — при подготовке очередной версии Cintu 16.04, уже с Cinnamon 3.2. К чему пока не готов ни я, ни состояние репозиториев этой среды.
А пока подведу предварительный итог. Диспетчер разделов KDE производит впечатление несколько недоделанной программы: отсутствуют пиктограммы инструментальной панели, в таблице поддерживаемых файловых систем фактически нет основной информационной нагрузки: какие действия для какой файловой системы доступны. Однако это более относится к косметике, нежели к функционалу. В отношении последнего же придраться почти не к чему: сбой при восстановлении раздела из резервной копии, возможно, связан с тем, что я сам что-то напортачил. Во всяком случае, до повторной проверки этой операции считать это сбоем не могу.
Требует проверки также способность работы диспетчера разделов KDE с ZFS, чем я планирую заняться в блиайшее время. Если поддержка этой системы размещения данный окажется реальной — это выведет KDE’шного диспетчера минимум на полкорпуса вперёд относительно GParted’а. Хотя и без того он имеет против последнего маленький, но жирный плюсик: запрос подтверждения на выполнение такой необратимой операции, как создание новой таблицы разделов.