Полученный раздел неправильно выровнен для лучшей производительности
Я пытаюсь разбить, но получить следующую ошибку -
The resulting partition is not properly aligned for best performance.
(parted) print
Model: Seagate BUP Slim Mac SL (scsi)
Disk /dev/sdd: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Number Start End Size File system Name Flags
(parted) mkpart
Partition name? []? part1
File system type? [ext2]? ext4
Start? 10
End? 100
Warning: The resulting partition is not properly aligned for best performance.
4 ответа
Загрузите данные из несогласованного раздела, удалите и заново создайте раздел с помощью gparted, убедившись, что установлено следующее:
Восстановите свои данные после завершения.
Не видя вывода команды unit s print после создания раздела, я не могу быть уверен в том, что здесь происходит. Я просто попробовал это на USB-накопителе и не получил такого предупреждения; но этот диск также сообщает размер физического сектора 512 байтов, а не 4096 байт вашего диска. Кроме того, вы не говорите, какую версию Ubuntu или parted вы используете (я использую Ubuntu 16.04 и parted 3.2-15).
В любом случае, мой unit s print output:
Number Start End Size File system Name Flags
1 20480s 194559s 174080s part1
Это правильно выровнено на большинстве дисков.
Для резервного копирования существует несколько причин, по которым разделы должны быть «выровнены», то есть созданы на кратные номера некоторых секторов. Причины включают:
Многие современные жесткие диски используют 4096-байтовые физические сектора; но для улучшения совместимости они делят каждый из них на восемь 512-байтовых логических секторов. Проблема в том, что если вы должны писать меньше, чем все восемь из этих логических секторов, диск должен будет прочитать полный физический сектор, изменить его и записать результат обратно на диск. Это займет больше времени, чем написание полного физического сектора (т. Е. Всех восьми логических секторов). Поскольку многие файловые системы используют структуры данных размером 4096 байт или больше, запуск файловой системы (раздела) на чем-то, отличном от границы с восемью секторами, может привести к серьезному ухудшению производительности. См. Эту статью, которую я написал для IBM developerWorks для получения дополнительной информации по этому вопросу, включая контрольные тесты, показывающие степень деградации, которая может возникнуть. (Оговорка: я провела эти тесты несколько лет назад. Результаты могут отличаться в настоящее время из-за изменений в оборудовании или программном обеспечении.) В некоторых типах конфигурации RAID данные «чередуются» на нескольких дисках. Это может привести к повышению производительности, но эти улучшения лучше всего, если разделы разбиты со стартовыми точками в кратность размера полосы, которая обычно находится в диапазоне от 16 KiB до 256 KiB. SSD могут видеть эффекты производительности и долговечности на основе размера блока стирания, который обычно составляет 512 KiB до 1 MiB, хотя я слышал о SSD со специфическими размерами блоков стирания, такими как 3 MiB.В большинстве случаев выравнивание по границам 2048 секторов (1 MiB) хорошо работает для всех этих технологий. (SSD с размером блока стирания 3 MiB будет исключением из этого правила.) Это значение стало стандартным для большинства инструментов разбиения. В зависимости от того, как parted интерпретировал ваш вход (единицы и т. Д.) И как он определяет оптимальное выравнивание ваших разделов, вы можете или могли бы иметь реальную проблему. Вот почему я сказал, что вам нужно посмотреть на выход unit s print. (Часть unit s имеет решающее значение, без этой части parted покажет начальные и конечные точки раздела, округленные до MiB, GiB или другое значение, что недостаточно точно для определения правильного выравнивания.)
Есть случаи, когда parted, как известно, жалуется без причины. Например, невозможно правильно выровнять расширенные разделы на дисках MBR, поскольку только реальные структуры данных этих разделов имеют размер 512 байт; но parted (или некоторые версии этого, так или иначе) будут жаловаться, если расширенный раздел не запускается на границе выравнивания. IIRC, некоторые версии также смотрят на после раздела, но это не имеет значения, за исключением того, что это может повлиять на начальную точку следующего раздела.
Один последний момент: в моем test parted обработал начальную точку 10 как 10 МиБ - или, более вероятно, как 10 МБ, а затем закруглен для правильного выравнивания. Похоже, что он обработал конечную точку 100 как 100 МБ и снова округлил ее для выравнивания. В любом случае начальная точка 10 MiB (результат после округления) оставляет начало до 10 Мибайт неиспользуемого пространства в начале диска. Даже с 1 выравниванием MiB, это 9 MiB неиспользуемого пространства. Это не большой объем пространства на современном диске, но вы можете захотеть пересмотреть и запустить первый раздел в 1 MiB.
Загрузите данные из несогласованного раздела, удалите и заново создайте раздел с помощью gparted, убедившись, что установлено следующее:
Восстановите свои данные после завершения.
Не видя вывода команды unit s print после создания раздела, я не могу быть уверен в том, что здесь происходит. Я просто попробовал это на USB-накопителе и не получил такого предупреждения; но этот диск также сообщает размер физического сектора 512 байтов, а не 4096 байт вашего диска. Кроме того, вы не говорите, какую версию Ubuntu или parted вы используете (я использую Ubuntu 16.04 и parted 3.2-15).
В любом случае, мой unit s print output:
Number Start End Size File system Name Flags
1 20480s 194559s 174080s part1
Это правильно выровнено на большинстве дисков.
Для резервного копирования существует несколько причин, по которым разделы должны быть «выровнены», то есть созданы на кратные номера некоторых секторов. Причины включают:
Многие современные жесткие диски используют 4096-байтовые физические сектора; но для улучшения совместимости они делят каждый из них на восемь 512-байтовых логических секторов. Проблема в том, что если вы должны писать меньше, чем все восемь из этих логических секторов, диск должен будет прочитать полный физический сектор, изменить его и записать результат обратно на диск. Это займет больше времени, чем написание полного физического сектора (т. Е. Всех восьми логических секторов). Поскольку многие файловые системы используют структуры данных размером 4096 байт или больше, запуск файловой системы (раздела) на чем-то, отличном от границы с восемью секторами, может привести к серьезному ухудшению производительности. См. Эту статью, которую я написал для IBM developerWorks для получения дополнительной информации по этому вопросу, включая контрольные тесты, показывающие степень деградации, которая может возникнуть. (Оговорка: я провела эти тесты несколько лет назад. Результаты могут отличаться в настоящее время из-за изменений в оборудовании или программном обеспечении.) В некоторых типах конфигурации RAID данные «чередуются» на нескольких дисках. Это может привести к повышению производительности, но эти улучшения лучше всего, если разделы разбиты со стартовыми точками в кратность размера полосы, которая обычно находится в диапазоне от 16 KiB до 256 KiB. SSD могут видеть эффекты производительности и долговечности на основе размера блока стирания, который обычно составляет 512 KiB до 1 MiB, хотя я слышал о SSD со специфическими размерами блоков стирания, такими как 3 MiB.В большинстве случаев выравнивание по границам 2048 секторов (1 MiB) хорошо работает для всех этих технологий. (SSD с размером блока стирания 3 MiB будет исключением из этого правила.) Это значение стало стандартным для большинства инструментов разбиения. В зависимости от того, как parted интерпретировал ваш вход (единицы и т. Д.) И как он определяет оптимальное выравнивание ваших разделов, вы можете или могли бы иметь реальную проблему. Вот почему я сказал, что вам нужно посмотреть на выход unit s print. (Часть unit s имеет решающее значение, без этой части parted покажет начальные и конечные точки раздела, округленные до MiB, GiB или другое значение, что недостаточно точно для определения правильного выравнивания.)
Есть случаи, когда parted, как известно, жалуется без причины. Например, невозможно правильно выровнять расширенные разделы на дисках MBR, поскольку только реальные структуры данных этих разделов имеют размер 512 байт; но parted (или некоторые версии этого, так или иначе) будут жаловаться, если расширенный раздел не запускается на границе выравнивания. IIRC, некоторые версии также смотрят на после раздела, но это не имеет значения, за исключением того, что это может повлиять на начальную точку следующего раздела.
Один последний момент: в моем test parted обработал начальную точку 10 как 10 МиБ - или, более вероятно, как 10 МБ, а затем закруглен для правильного выравнивания. Похоже, что он обработал конечную точку 100 как 100 МБ и снова округлил ее для выравнивания. В любом случае начальная точка 10 MiB (результат после округления) оставляет начало до 10 Мибайт неиспользуемого пространства в начале диска. Даже с 1 выравниванием MiB, это 9 MiB неиспользуемого пространства. Это не большой объем пространства на современном диске, но вы можете захотеть пересмотреть и запустить первый раздел в 1 MiB.