Получающийся раздел не выровнен должным образом для лучшей производительности

Скопируйте данные из неправильно выровненного раздела, удалите и воссоздайте использование раздела gparted, удостоверяясь, что следующее установлено как показано...

Восстановите свои данные, когда завершенный.

Не видя вывода a unit s print команда после создания раздела, я не могу быть уверен в том, что продолжается здесь. Я просто попробовал это на карте флэш-памяти с интерфейсом USB и не получил такого предупреждения; но тот диск также сообщает о физическом размере сектора 512 байтов, не 4 096 байтов Вашего диска. Кроме того, Вы не говорите что версия Ubuntu или parted Вы используете (я использую Ubuntu 16.04 и parted 3.2-15).

В любом случае, мой unit s print вывод:

Number  Start   End      Size     File system  Name   Flags
 1      20480s  194559s  174080s               part1

Это правильно выровненное на большинстве дисков.

Для резервного копирования существует несколько причин, почему разделы должны быть "выровненные" - то есть, созданы на кратных числах определенных номеров секторов. Причины включают:

• Много современных жестких дисков используют 4 096-байтовые физические секторы; но улучшить совместимость, они делят каждый из них в восемь 512-байтовых логических секторов. Проблема состоит в том, что, если бы необходимо было записать в меньше, чем все восемь из тех логических секторов, диск должен был бы считать весь физический сектор, изменить его и записать результат обратно к диску. Это заняло бы больше времени, чем запись всего физического сектора (то есть, все восемь из его логических секторов). Поскольку много файловых систем используют структуры данных, которые составляют 4 096 байтов или больше, запуская файловую систему (раздел) на чем-то другом, чем граница с восемью секторами может вызвать серьезное снижение производительности. См. эту статью, для которой я написал для IBM developerWorks больше на этом предмете, включая оценочные испытания, показывающие количество неисправности, которая может закончиться. (Протест: Я сделал те тесты несколько лет назад. Результаты могли бы отличаться теперь из-за изменений в аппаратных средствах или программном обеспечении.)
• В некоторых типах конфигурации RAID данные "чередуются" через несколько дисков. Это может привести к повышениям производительности, но те улучшения являются лучшими, если разделы размечаются с начальными точками в кратных числах размера дорожки, который обычно находится в 16 кибибайтах к диапазону 256 кибибайт размером.
• SSD видят производительность и эффекты долговечности на основе их размера блока стирания, который обычно является 512 кибибайтами к 1 мебибайт, хотя я услышал о SSD со специфическими размерами блока стирания, такими как 3 мебибайт.

В большинстве случаев выравнивание на границах (на 1 мебибайт) с 2048 секторами работает хорошо на все эти технологии. (SSD с размером блока стирания на 3 мебибайт был бы исключением к этому правилу.) Это значение стало значением по умолчанию для большинства инструментов разделения. В зависимости от как parted интерпретируемый Ваш вход (единицы, и т.д.) и как это определяет, оптимально ли Ваши разделы выровненные, Вы могли бы или могли бы иметь настоящую проблему. Вот почему я сказал, что необходимо посмотреть на unit s print вывод. ( unit s часть очень важна; без той части, parted покажет Вам, раздел запускается и конечные точки, округленные к мебибайт, гибибайту или некоторому другому значению, которое не достаточно точно для определения надлежащего выравнивания.)

Существуют случаи в который parted как известно, жалуется без причины. Например, невозможно правильно выровнять расширенные разделы на дисках MBR, так как единственные реальные структуры данных этих разделов составляют 512 байтов в размере; но parted (или некоторые версии его, во всяком случае), будет жаловаться, не запускается ли расширенный раздел на границе выравнивания. IIRC, некоторые версии также смотрят на конечную точку раздела, но это не релевантно, кроме того, поскольку это может влиять на стартовую точку следующего раздела.

Один конечный пункт: В моем тесте, parted рассматриваемый стартовая точка 10 как 10 мебибайт - или более вероятно, как 10 МБ, и затем округленный для надлежащего выравнивания. Это затем, кажется, рассматривало 100 конечная точка как 100 МБ, и снова округленный это для выравнивания. В любом случае 10 мебибайт (результат после округления) стартовая точка уезжают близко к 10 мебибайт неиспользуемого места в начале диска. Даже с выравниванием на 1 мебибайт, это составляет 9 мебибайт неиспользуемого места. Это не большая сумма пространства на современном диске, но Вы могли бы хотеть пересмотреть и запустить первый раздел на уровне 1 мебибайт.