У меня большая файловая система ext4, которую я сейчас сжимаю (109 ТБ -> 83 ТБ в моем случае), и это занимает очень много времени (День 5, как я просил). В настоящее время я вижу, что процесс все еще выполняет ввод-вывод (поэтому кажется, что он не ошибся и не остановился, т.е. 100% использование процессора) через iotop. Однако при беглом взгляде на Интернет может показаться, что resize2fs не так оптимизирован для сжатия, как для увеличения объемов (около 2011 г.).
В этом отношении я не хочу прерывать его, если я могу помочь, но я чувствую себя немного голым, работая над изменением файловой системы так долго. Что было бы хорошей / своевременной оценкой для сжатия ext4, учитывая, что мы знаем требования к пространству до и после (а также количество блоков / размеров блоков)
Задействованное программное обеспечение:
e2fs...: 1.43.1debian 4.19.16-1-bpo9+1Моя конкретная файловая система:
Текущие выходы:
resize2fs -p ...:
[root@devlynx]## ~:: resize2fs -p /dev/storage/storage 83T
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/storage/storage to 22280142848 (4k) blocks.
Begin pass 2 (max = 802451420)
Relocating blocks 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)
Resizing the filesystem on /dev/storage/storage to 22280142848 (4k) blocks.
Begin pass 2 (max = 802451420)
Relocating blocks XX--------------------------------------
Begin pass 3 (max = 894088)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 92164)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/storage/storage is now 22280142848 (4k) blocks long.
Грубые оценки могут помочь проиллюстрировать масштаб объекта, даже если он упрощен и не совсем точен или точен. Предположим, что необходимо прочитать все 1,2E + 14 байтов, и можно поддерживать 4E + 7 байтов в секунду. Это 3E + 6 секунд или 34 дня. resize2fs 5% индикатор выполнения примерно за 5 дней кажется верной степенью 10.
По крайней мере, недели.
Когда этот том нужно вернуть в эксплуатацию? Другая срочность для чего-то, что нужно поднять сейчас, по сравнению с архивом без немедленного использования, на который вы можете потратить месяц.
Готовы ли вы к потере данных в случае прерывания? Нет никакого изящного способа остановить это, поэтому есть шанс коррупции. Успешные сокращения случались, но обычно не выполняются, а остановка сокращения посреди перетасовки блоков еще хуже. Что бы ни случилось с этой файловой системой, проверьте согласованность с fsck. Подготовьте план восстановления с резервными копиями важных данных.
Следует ли еще уменьшить этот объем, даже если эта попытка закончится неудачей? Безопасный способ - создать новую файловую систему меньшего размера и скопировать данные. Очевидный недостаток, это требует нового хранилища. Возможно, воспользуйтесь возможностью выполнить миграцию хранилища или другие вещи, требующие перестройки массива или чего-то подобного.