КРАТКОЕ СОДЕРЖАНИЕ
У меня есть ноутбук Dell Inspiron 17-5767 с внутренним диском на 1 ТБ, на котором я оставил изначально поставленную Windows 10, чтобы она продолжала доминировать (это моя игровая ОС). Кроме того, у меня есть два внешних диска, с которых я загружаю и буду загружать свою текущую и будущую ОС Linux. Моя текущая настройка выглядит следующим образом:
- Порт USB 3.0 № 0: Seagate Expansion+ 931,5 ГиБ (1000204885504 байт) Внешний жесткий диск распознается как /dev/sdb
- в настоящее время размещен один полноразмерный пустой раздел ext4, но возникли трудности с заменой его на оптимальную выровненную схему разбиения на разделы из 12 разделов (главная проблема — с выравниванием)
- Порт USB 3.0 № 1: 238,5 ГиБ (256060514304 байт) Samsung SSD 840 Pro распознается как /dev/sdc
- был разбит на разделы с помощью установщика Fedora LiveCD (с опцией «пользовательский») и содержит оба моих дистрибутива Fedora LXDE и Lubuntu Linux в одном LVM, содержащем общее пространство подкачки, общее пользовательское пространство, отдельные корневые каталоги и отдельные внешние загрузочные разделы (под внешними я подразумеваю не LVM, а их собственные отдельные основные разделы в другом месте на том же диске)
- Этот диск имеет как физический, так и логический размер блока 512 и оптимально выровнен, согласно утилите parted 'align-check opt x', и fdisk также доволен выравниванием (никаких жалоб на выравнивание от какой-либо утилиты)
- UEFI BIOS пытается загрузиться с USB-накопителя до загрузки с внутреннего накопителя, поэтому у меня выскакивает grub со всеми доступными параметрами
ЦЕЛЬ
Я пытаюсь воспроизвести что-то вроде того, что у меня происходит с /dev/sdc на диске /dev/sdb, но с 5 дистрибутивами Linux. Этот аспект моего проекта я охватил, поскольку я опытный мультизагрузчик. Но другая часть моей цели заключается в том, чтобы мои разделы на /dev/sdb были оптимально выровнены, как в случае с /dev/sdc, и вот тут-то я и сталкиваюсь с проблемой.
СРЕДА
В настоящее время я работаю в своей относительно свежей и обновленной установке Fedora LXDE, и результаты, которые я получаю, полностью повторяются в моей также относительно свежей и обновленной установке Lubuntu.
СООБЩЕННЫЕ ПАРАМЕТРЫ ДИСКА
[root@frank ~]# cat /sys/class/block/sdb/queue/physical_block_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/logical_block_size
512
[root@frank ~]# cat /sys/class/block/sdb/queue/minimum_io_size
4096
[root@frank ~]# cat /sys/class/block/sdb/queue/optimal_io_size
33553920
[root@frank ~]# cat /sys/class/block/sdb/alignment_offset
0
[root@frank ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 931.5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 9428D9DB-746C-40CA-B189-060F92A10E3C
Device Start End Sectors Size Type
/dev/sdb1 65535 1953467279 1953401745 931.5G Linux filesystem
Partition 1 does not start on physical sector boundary.
[root@frank ~]#
ПРОБЛЕМА
Итак, судя по сообщению о размере физического блока, диск имеет размер 4k (расширенный формат), а не 512b, как у другого диска, хотя в целях обратной совместимости он использует размер логического сектора 512b. Я могу сказать, что утилита GNU parted предполагает размер блока 512, потому что при расчете оптимального интервала ввода-вывода
(optimal_io_size + alignment_offset) / physical_block_size = optimal_sector_interval
он получает значение 65535, с которого он автоматически начнет первый раздел, и единственный способ, которым подпрограмма align-check сочтет выравнивание раздела оптимальным, — это если оно начнется с числа, кратного 65535. Единственный способ, которым результат parted имеет смысл, — это если вы учтете, что он обрабатывает physical_io_size как 512 вместо 4096.
(33553920 + 0) / 512 = 65535.
Однако parted по понятным причинам не может использовать размер блока 4096, поскольку тогда уравнение будет выглядеть так:
(33553920 + 0) / 4096 = 8191.875.
Этот ответ удовлетворил бы учителя алгебры в старшей школе, но, очевидно, не имеет смысла как интервал сектора, для которого можно было бы ожидать дискретного значения (т. е. целого числа!). В любом случае, поскольку я хочу создать 12 разделов, некоторые из которых имеют размер всего 256 МБ, это невозможно сделать в GNU Parted с использованием процентов, и, если говорить коротко, я смог удовлетворить проверки выравнивания для оптимального выравнивания, придерживаясь «единиц s» и выполняя модульную арифметику самостоятельно, чтобы гарантировать, что мои разделы начинаются с интервалов 65535s, как и хотел parted. Основываясь на своих исследованиях, я не думал, что было так важно гарантировать, что мои разделы также заканчиваются этими интервалами, и, следовательно, у меня остались зазоры (очевидно, не больше 65535) между большинством моих разделов.
И снова parted посчитал, что мой результат был оптимально выровнен, посчитав размер физического блока равным 512 вместо 4096. Но затем после выхода из parted и запуска «fdisk -l /dev/sdb» я получил в выводе следующее:
Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.
Partition 9 does not start on physical sector boundary.
Partition 10 does not start on physical sector boundary.
Partition 11 does not start on physical sector boundary.
Partition 12 does not start on physical sector boundary.
Итак, то, что нравится parted, не нравится fdisk. Поэтому я попытался использовать gParted, чтобы переделать мою схему разбиения, позволив ему использовать 1 МБ в качестве размера блока, и он начал первый раздел с 2048, как вы могли видеть на моем другом диске (/dev/sdc). После этого fdisk был счастлив и перестал жаловаться на выравнивание секторов, но затем GNU parted не прошел тесты проверки выравнивания для оптимального режима, хотя он прошел для минимального режима.
Однако я обнаружил, что в обоих случаях mkswap (который я использовал для создания тома подкачки в LVM, размещенном на /dev/sdb11) выдал мне следующее предупреждение:
[root@frank ~]# mkswap /dev/strange_quark_experimental/swap
mkswap: warning: /dev/strange_quark_experimental/swap is misaligned
Таким образом, mkswap обнаруживает, что мой том подкачки выровнен некорректно, независимо от того, считает ли parted, что диск выровнен оптимально или минимально, и mkswap также обнаруживает, что мой том подкачки выровнен некорректно, независимо от того, устраивает ли fdisk выравнивание или нет.
ТЕОРИИ
Все это оставляет у меня впечатление, что мне, возможно, придется игнорировать предупреждения по крайней мере от одной утилиты для создания отчетов о диске или разбиения на разделы, но я не уверен, от какой именно. Также возможно, что все отчеты изначально ненадежны, поскольку совместимый с USB корпус, содержащий жесткий диск, может неверно сообщать по крайней мере один из параметров сектора. Например, может быть, это на самом деле не диск AF? Или, может быть, его оптимальный размер ввода-вывода сообщается неверно. Или, может быть, и то, и другое? И, поверьте мне, я также рассматривал возможность того, что это случай PEBKAC, поскольку я мог просто неправильно понять что-то о том, как выравнивать разделы на диске 4k. Я не уверен.
Что бы ни происходило, я буду рад продолжить установку Linux, как только удостоверюсь, что мои разделы оптимально выровнены, а mkswap или, по крайней мере, утилиты, которым я действительно должен доверять больше всего, перестанут жаловаться на выравнивание.
ПОМОЩЬ
Пожалуйста, помогите мне понять, почему мне не удаётся заставить parted и другие дисковые утилиты согласовать что-либо большее, чем минимальное выравнивание (достигается только при разбиении с помощью gParted или gdisk), и, пожалуйста, посоветуйте мне, стоит ли мне слишком беспокоиться о преимуществах оптимального выравнивания над минимальным в моём случае, поскольку я не собираюсь тратить время, если разница в производительности или состоянии диска будет слишком незначительной. В противном случае я хотел бы иметь возможность в полной мере воспользоваться преимуществами расширенного формата моего диска.
решение1
Если вас все еще смущает странное число 65535s. Я тоже недавно смущался этим вопросом. Я искал ответ и наткнулся на этот:http://gparted-forum.surf4.info/viewtopic.php?id=17839
Вкратце, optimize_io_size может быть недействительным, если жесткий диск подключен к ПК через адаптер usb-sata.
Решение — просто игнорировать это число и придерживаться рекомендуемой границы в 1 МиБ.