ext4 время на уменьшение

Ах да. Там оракловая база, так что все 5 теров заняты всего нескольими сотнями файлов по 16gb размером.

а vxfs при таких расскладах отрабатывает за секунды ^_^

Разумеется, оно будет перемещать все файлы к началу устройства, где файлуха лежит (что б ты потом мог пошринкать устройство). Поэтому, время зависит только от того, как много файлов придётся перемещать.

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

Можно еще попробовать в несколько этапов, например, шринкать по несколько гигабайт, сколько тебе времени дадут...

даже винда шринкает мгновенно до конца заполненного пространства.

мисье знатный извращенец. рассказывай уже историю ужасов о том как ты до такого докатился.

p.s. а меня еще спрашивали как-то тут зачем мне сдался онлайн шринк, вот и сдался...

А зачем ты делал 9.5Т, если там до 5Т доросло?

А зачем ты делал 9.5Т, если там до 5Т доросло?

Была миграция с аикса, со сменой версии оракла и конвертацией базы. Это место там было занято почти полностью.

Разумеется, оно будет перемещать все файлы к началу устройства, где файлуха лежит (что б ты потом мог пошринкать устройство). Поэтому, время зависит только от того, как много файлов придётся перемещать.

Это понятно. Но просто реальность не всегда укладывается с теорией.
В частности вот такое нагугливается http://www.redhat.com/archives/ext3-users/2011-June/msg00015.html
.

1 терабайт перемещать больше 2х суток это как-то страшно.

На сторадже еще 5Т найдется? Надежнее будет туда перенести, а эту ФС освободить.

до конца заполненного пространства.

все теоретически могут это сделать мгновенно

Предлагаю такой алгоритм: сначала для тестирования урежь раздел на 50Gb, посмотри сколько это займёт времени(если в конце данных нет - может быть недостоверно). Потом увеличивай в два раза объём данных и пробуй ещё. Время простоя будет возрастать постепенно, и ты увидишь, когда следующее будет уже неприемлимо долгим. Или не увидишь, и всё поресайзишь захода с 6-го.

Бэкап делать или нет? Если делать то куда? Если бэкап уже есть, не надежнее ли будет просто переделать раздел и восстановить данные? Скорость восстановления заранее известна.

Судя по тому, что это Oracle такого сурового объёма, бекап там уже должен быть :)

Мой вариант тоже предсказуем по времени, причём вероятно всё-таки быстрее чем полное восстановление

Если на сторадже есть 5Т, а я думаю на таком сторадже это не проблема, то лучше было бы восстанавливать туда, т.к. это не требует остановки Оракла (шринк то придется делать offline на размонтированном девайсе). Потом только дельту (по оракловым логам) докинуть на восстановленный раздел.

Мой вариант тоже предсказуем по времени

Не факт что они не запорят всё либо во время resize2fs либо потом при ресайзе LUNa на сторадже.

Ты можешь сказать сколько займет fsck -f (resize2fs требует это) для 9.5Т ФС?

Можно еще попробовать в несколько этапов, например, шринкать по несколько гигабайт, сколько тебе времени дадут...

И напороться на баги.

Лучше ваш первый вариант - defrag + shrink.

Судя по постановке задачи, ТС ограничен по месту на сторадже. Иначе создать новый раздел и скопировать туда, а потом довосстановить из write-ahead log(или как это у оракла называется) было бы логично.

fsck -f (resize2fs требует это)

Аргумент. Он его вызовет, даже если ФC в порядке? Я думал, fsck всякий там gparted и прочие вспомогательные тулзы вызывают, а не resize2fs.

Ну, наверное это можно как-то обойти tune2fs, пометить как чистую только что проверенную.

Ну, наверное это можно как-то обойти tune2fs

можно: tune2fs -T now /dev/$block_device

Но если там была неконсистентность результат может быть непредсказуемым.

бекап там уже должен быть

И бэкап есть и стендбай есть. Все как у белых людей.

Предлагаю такой алгоритм: сначала для тестирования урежь раздел на 50Gb,

Да я как раз надумал пробовать по чуток резать, так наверно и сделаю.

Ты отпишись потом, интересно чем закончится

Разумеется, оно будет перемещать все файлы к началу устройства

e4defrag сделай сначала

сколько займет fsck -f (resize2fs требует это) для 9.5Т ФС?

для 2Tb около минуты, в ext4 с этим гораздо лучше чем в ext3

для 2Tb около минуты, в ext4 с этим гораздо лучше чем в ext3

full (force) check (-f) ??? Не верю!

1. e4defrag
2. Разрабы обещали запилить онлайновый ресайз уже.

уже запилили*

ачо её искать? Палитесь, товарищ. Давно она уже есть в e2fs тулзах.

Хотелось бы добавить, что e4defrag с очень большой вероятностью эффекта не даст.

full (force) check (-f) ??? Не верю!

Про 9.5 теров не скажу. Но 4 тера минут 20 проверялось. Причем там неравномерно, если по % смотреть. Т.е. первые 10-15% медленно, а оставшееся очень быстро пробегает.

Где? В бтрфс видел, но бтрфс на продакшн... Я не такой смелый :) Или вы про дефрагметацию? Онлайн шринк бы...

Вообще с динамическим рулением ресурсами в линуксе все грустно. У нас привыкли к роскошной жизни на ibm pseries, и смотрят на меня не одобрительно, когда я разбиваю хотелки о суровую реальность возможностей линукса.:D

Вобщем я решил отдать место с другого стораджа и перетащить простым копированием. Истории успеха о шринке многотерабайтной фаловой системы под линукс в интенете так и не появится.

full (force) check (-f) ??? Не верю!

да слегка дольше, но все равно это гораздо быстрее ext3. вот раздел на 2Tb (на весь диск)

# time fsck.ext4 -f /dev/sdb1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdb3: 480515/122101760 files (39.7% non-contiguous), 484584068/488377856 blocks

real    4m38.987s
user    0m45.576s
sys     0m6.164s

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

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