Как я могу переместить, на месте, корневой раздел экземпляра AWS t2.micro?
Ситуация: У меня Ubuntu 14.04.5 настроен на экземпляр AWS t2.micro, используя хранилище SSD EBS (основной экземпляр). При успешном изменении размера корневого раздела с 8 GiB до 12 GiB я получил предупреждение: «Полученный раздел не правильно выровнен для лучшей производительности». Я исследовал способы решения этой проблемы, но ни один из них не соответствует моим требованиям для использования параметров командной строки во вторичном экземпляре для изменения остановленного и отсоединенного тома основного экземпляра (SOP для обработки экземпляров AWS).
В ответ на ответ @ Michael отредактировано следующее:
Используя blkid и parted, я нашел эту конфигурацию для моего существующего раздела:
root@<domain>:~# blkid
/dev/xvda1: LABEL="cloudimg-rootfx" UUID="<uuid>" TYPE="ext4"
root@<domain>:~# parted
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 25165824s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 16065s 25165823s 25149759s primary ext4 boot
(parted) quit
root@<domain>:~#
After рассматривая несколько источников и [это, в частности,] http://rainbow.chard.org/2013/01/30/how-to-align-partitions-for-best-performance-using-parted/ анализ показывает желаемый оптимальный Конфигурация:
Disk /dev/xvda: 25165824s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 2048s 25165823s 25163776s primary ext4 boot
Еще раз проверяя мою конфигурацию, я обнаружил следующие свойства ввода-вывода:
root@domain:/# cat /sys/block/xvda/queue/optimal_io_size 0
root@domain:/# cat /sys/block/xvda/queue/minimum_io_size 512
root@domain:/# cat /sys/block/xvda/alignment_offset 0
root@domain:/# cat /sys/block/xvda/queue/physical_block_size 512
root@domain:/# parted /dev/xvda
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) align-check minimal 1
1 aligned
(parted) align-check optimal 1
1 not aligned
, что указывает на то, что раздел не оптимально выровнен и (по ссылке блога), что оптимальное выравнивание составляет 1 MiB / 2048s.
Я хотел бы использовать разделенные (или другие параметры командной строки), чтобы переместить раздел на месте с начала с 16065 года до начала с 2048-х годов, с окончанием раздела в конце диск, 25165823s. Это может быть сделано как два шага; сначала переместите раздел без изменения размера, а затем операцию изменения размера. Или, если возможно, переместите и измените размер за одну операцию. Конечно, я сделал бы снимок остановленного основного экземпляра перед внесением любых изменений, и я бы использовал дополнительный экземпляр для работы в разделе / файловой системе первичного экземпляра.
Мои вопросы:
1. Можно ли использовать подкоманду parted move для этого? Если да, то как? 2. Существуют ли операции очистки, необходимые для обеспечения загрузки измененного раздела (после отсоединения от вторичного экземпляра и повторного подключения к основному экземпляру)? 3. Любые другие предложения для подхода? 4. Почему это предупреждение, хотя ответ @ Майкла указывает, что выравнивание уже оптимально?DVHirst
2 ответа
Сообщение кажется мне неправильным.
16065 - это то, где корневой раздел начинается с экземпляров, запущенных из официальных AMI Ubuntu на AWS.
Disk /dev/xvda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Device Boot Start End Blocks Id System
/dev/xvda1 * 16065 16771859 8377897+ 83 Linux
Учитывая, что объем EBS требует 255 голов и 63 треков, 16065, казалось бы, находится в идеальном теоретическом выравнивании, как 63 и раз; 255 = 16065 ... поэтому, полагая, что моя математика правильная, это первый сектор первого трека на втором цилиндре, хотя ни одна из этих геометрий не является реальной, поскольку диск является томом EBS.
Я был бы склонен оставить это точно так, как есть. Если это неправильно, похоже, что Canonical и / или AWS имеют некоторые объяснения, учитывая множество миллионов экземпляров именно с такой конфигурацией.
Сообщение кажется мне неправильным.
16065 - это то, где корневой раздел начинается с экземпляров, запущенных из официальных AMI Ubuntu на AWS.
Disk /dev/xvda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors
Device Boot Start End Blocks Id System
/dev/xvda1 * 16065 16771859 8377897+ 83 Linux
Учитывая, что объем EBS требует 255 голов и 63 треков, 16065, казалось бы, находится в идеальном теоретическом выравнивании, как 63 и раз; 255 = 16065 ... поэтому, полагая, что моя математика правильная, это первый сектор первого трека на втором цилиндре, хотя ни одна из этих геометрий не является реальной, поскольку диск является томом EBS.
Я был бы склонен оставить это точно так, как есть. Если это неправильно, похоже, что Canonical и / или AWS имеют некоторые объяснения, учитывая множество миллионов экземпляров именно с такой конфигурацией.
-
1Я слышу вас, особенно ваш последний параграф; Мне тоже хотелось бы что-то увидеть от AWS по этой теме. Назовите меня смущенным. – dvhirst 1 June 2017 в 09:17