Я должен сделать раздел на объеме EBS? Что лучше?

Для меня в EC2 действительно имеет смысл использовать весь том для файловой системы только из-за гибкости, допускаемой томами Elastic Block Store (EBS), которые сильно отличаются от многих физических дисков, в том смысле, что Вы можете предоставлять их по мере необходимости, уничтожать их по мере необходимости, прикреплять и отсоединять их от экземпляров без перезагрузки, а также делать снимки и клонировать их без использования процессора, памяти или ввода-вывода экземпляра. А без таблицы разделов изменение размера, когда вам нужно больше места, - торт.

Нужна большая файловая система? Если вы используете весь том без таблицы разделов, это очень просто.

Сделайте снимок тома EBS с помощью консоли AWS, когда том еще подключен и используется. На самом деле вы не будете использовать этот снимок, но поверьте мне на минуту. Если вы недавно сделали моментальный снимок тома, но у него все еще есть, вы можете пропустить этот шаг, поскольку цель здесь - ускорить выполнение остальных шагов.

Размонтировать том.

Сделайте второй снимок. Это тот, который вы хотите. Мы сделали предыдущий, потому что он сделает этот снимок намного быстрее. Когда EBS делает снимок, он сохраняет содержимое диска в скрытом хранилище на S3. Для каждого последовательного снимка одного и того же тома необходимо сохранять только измененные блоки , поэтому этот снимок будет создаваться, в основном, с сохраненными указателями на местоположение всех уже захваченных данных и только измененные блоки будут физически сохранены.

Создайте новый том, используя последний снимок.

Прикрепите новый том к экземпляру вместо старого и смонтируйте его. Проверьте данные при необходимости.

Затем вы можете использовать resize2fs, чтобы увеличить файловую систему, чтобы заполнить доступный размер на новом томе, пока он используется.

Затем удалите первый снимок выше. EBS будет «откатывать» все, что в нем содержится, что также необходимо для окончательного снимка, поэтому окончательный снимок остается в силе.

В качестве последнего шага, вы можете разогреть новую громкость с помощью sudo dd if=/dev/xvdx of=/dev/null bs=1M. Когда том создается из моментального снимка, содержимое тома «лениво» загружается из моментального снимка на фактический том, что означает, что том становится полностью доступным, прежде чем его производительность станет оптимальной. Если вы попросите что-то из тома, который еще не был загружен фоновым процессом, вы все равно получите это почти сразу, но не так быстро, как если бы фоновый процесс загрузил все. Операция dd, приведенная выше, выполняет физическое чтение всего тома, в результате чего все это становится доступным с наименьшей возможной задержкой, быстрее, чем это могло бы быть в противном случае. Это задокументировано как то, что должно быть сделано с отключенным томом, но неважно, делаете ли вы это до или после изменения размера. Различные варианты предварительного нагрева томов EBS обсуждаются на http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-prewarm.html ...

Для меня использование всего тома для файловой системы без таблицы разделов кажется единственным выходом, поскольку сводит к минимуму время простоя и возможность ошибок. Все мои EBS (и эфемерные, в этом отношении) тома сделаны таким образом, за исключением некоторых очень ранних.

Конечно, вы можете использовать fdisk или parted для создания и изменения таблицы разделов обычным способом, но - на мой взгляд - это неоправданное добавление дополнительных «движущихся частей» ... которые обычно означает больше возможностей для ошибки.

Если вы знаете, как заставить X-сервер вашего локального компьютера работать и принимать входящие соединения от экземпляра EC2 для локального отображения вывода графического интерфейса, вы также можете легко использовать графический инструмент gparted на экземплярах EC2 с графический интерфейс, отображаемый на экране вашей локальной рабочей станции - да, это работает, я сделал это, - но эта работа выходит за рамки этого вопроса.