Оценка времени, необходимого для сжатия resize2fs

У меня есть большая файловая система ext4, которую я в настоящее время уменьшаю (109 Тб -> 83 Тб в моем случае), и это занимает чрезвычайно много времени (5-й день на момент запроса). В настоящее время я вижу, что процесс все еще выполняет операции ввода-вывода (так что, похоже, он не выдал ошибку и не завис, т.е. 100% загрузка процессора) через iotop. Однако, судя по беглому взгляду на интернет, кажется, что resize2fs не был так оптимизирован для уменьшения объемов, как для их увеличения (около 2011 года).

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

Используемое программное обеспечение:

• e2fs…: 1.43.1
• ОС: debian 4.19.16-1-bpo9+1

Моя конкретная файловая система:

• Тип: ext4
• Размер: ~109 Тб (29297465344 блоков)
• Уменьшить до: 83 Тб (22280142848 блоков)
• Размер блока: 4 Кб (4096 байт)
• байт на inode: 2^15 (32786 байт)

Текущие выводы:

resize2fs -p ...:

[root@devlynx]## ~:: resize2fs -p /dev/storage/storage 83T
resize2fs 1.43.4 (31-Jan-2017)
Изменение размера файловой системы на /dev/storage/storage до 22280142848 (4k) блоков.
Начинается проход 2 (макс = 802451420)
Перемещение блоков             XX--------------------------------------

iotop:

   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  7282 be/4 root       39.21 M/s   39.21 M/s  0.00 % 94.07 % resize2fs -p /dev/storage/storage 83T

cat /proc/7282/io:

rchar: 12992021859371
wchar: 12988874121611
syscr: 13244258
syscw: 12482026
read_bytes: 13003899662336
write_bytes: 12988874125312
cancelled_write_bytes: 0

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

Правка: Это действительно законченный проход 2?

[root@devlynx]## ~:: resize2fs -p /dev/storage/storage 83T
resize2fs 1.43.4 (31-Jan-2017)
Изменение размера файловой системы на /dev/storage/storage до 22280142848 (4k) блоков.
Начинается проход 2 (макс = 802451420)
Перемещение блоков             XX--------------------------------------
Начинается проход 3 (макс = 894088)
Сканирование таблицы inode          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Начинается проход 4 (макс = 92164)
Обновление ссылок inode     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Файловая система на /dev/storage/storage теперь имеет размер 22280142848 (4k) блоков.

Поскольку есть только один другой ответ, я решил поделиться своим ограниченным опытом.

Мой опыт работы с ~5 уменьшениями resize2fs показал, что деление объема, который нужно уменьшить (109 Тб – 83 Тб = 26 Тб в случае автора вопроса), на скорость записи, как сообщают такие инструменты, как iotop, дает оценку времени, которая несколько больше, чем фактическое время процесса; мои изменения размеров заняли 70-90% этого времени.

Автор вопроса сообщил в комментарии к ответу Джона Маховала, что окончательный процесс занял “около недели”. Это совпадает с моим опытом, поскольку автор вопроса сообщил о скорости 40 мегабит/сек по данным iotop. 40 * 60 * 60 * 24 * 7 = 24,192,000 мегабит, или около 23 Тб, что составляет около 88.7% от размера уменьшения в 26 Тб.

Я всегда уменьшал до минимального размера, необходимого для хранения данных (-M), и я предположу, что такое уменьшение займет больше времени, чем уменьшение объема, который в основном пуст, так как можем представить, что меньше выделенных блоков потребуется переместить.

Опыт автора вопроса с “индикатором прогресса” прохода 2 совпадает с моим: я не смог получить никакого значительного указания прогресса, и проход 2 всегда заканчивается с почти пустым индикатором прогресса. Более того, количество X на “индикаторе прогресса” увеличивается и уменьшается в моем опыте, иногда поднимаясь и опускаясь несколько раз. Я видел, как оно увеличивалось до 8 X, затем уменьшалось до 0 и заканчивалось на 0. Я также видел его завершение с другими числами X, например, двумя или шестью. Я не знаю, как интерпретировать то, что говорит мне этот “индикатор прогресса”, и намерен задать свой собственный вопрос по этому поводу.

Медленная скорость передачи данных автора вопроса также совпадает с моим опытом. Мои изменения размеров происходили на скорости около 40 мегабит/сек, несмотря на то, что диски в данном случае могли обеспечить скорость последовательной записи 80-120 мегабит/сек. Мои блоки имеют размер 4 Кб. Если диск перемещает по одному блоку за раз, это, вероятно, похоже на случайный 4 Кб чтение/запись — операция, требующая много позиционирования. Процесс resize2fs также, похоже, потреблял один целый процессор (100% использования ЦП).

Грубые оценки могут помочь проиллюстрировать масштаб задачи, даже если они просты и совершенно не точны или неаккуратны. Предположим, что все 1.2E+14 байт необходимо прочитать, и можно поддерживать 4E+7 байт в секунду. Это 3E+6 секунд или 34 дня. resize2fs с индикатором прогресса 5% примерно через 5 дней кажется правильной десятичной степенью.

Недели вперед, как минимум.

Когда этот объем нужно вернуть в эксплуатацию? Разная срочность для чего-то, что нужно запустить сейчас, в отличие от архива, который не используется немедленно, и на который можно потратить месяц.

Готовы ли вы к потере данных, если это прервется? Нет “гладкого” способа остановить это, поэтому существует вероятность повреждения. Успешные уменьшения происходили, но они не распространены, и остановка уменьшения в середине перестановки блоков тем более не распространена. Что бы ни случилось с этой файловой системой, проверьте ее целостность с помощью fsck. Подготовьте план восстановления с резервными копиями важных данных.

Должен ли этот объем все еще быть уменьшен, даже если эта попытка закончится неудачей? Безопасный способ – создать новую, меньшую файловую систему и скопировать данные. Очевидный недостаток заключается в том, что это требует нового хранилища. Возможно, стоит воспользоваться возможностью для миграции хранилища или других операций, которые требуют перестройки массива или подобного.