Есть e2fsck -D, но, ИМХО, это не то, что вам хочется.

можно ли как-то этот размер уменьшить

Да:

mkdir dir1.new
mv dir1/* dir1.new/
mv dir1/.* dir1.new/
rm -rf dir1/
mv dir1.new dir1

Ну, идею Вы поняли. А так, насколько я знаю, ext4 никогда не reclaim’ает место занятое директорией.

Edit: правда это не совсем вяжется с «Не хочется его пересоздавать», почему?

Да, я понял. Чтоб процессы не прекращать, не хотелось пересоздавать. Ну да деваться некуда, спасибо.

а если натравить дефрагментатор ?? вполне вероятно они метадату пожмет.

На некоторых файловых системах операция выполнима с открытыми файлами.

А не поможет переименование файлов одного за другим из этого каталога в другой на той же фс и обратно в этот?

Если так подходить к задаче - лучше применить не просто копирование, а жесткую или символьную ссылку ФС. Тогда можно пошаманить с содержимым каталога в фоне, а когда будет готово - стопануть сервисы, поменять source ссылки, и стартануть сервисы обратно. Такой финт ушами позволит уменьшить время рестарта системы до минимума.

символьные - не надо.

Символьная ссылка это явно не то.

А вот с жесткими ссылками можно было бы поиграться. Но лично моей квалификации для понимания всех происходящих при этом процессов не хватит.

Есть e2fsck -D, но, ИМХО, это не то, что вам хочется.

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

e2fsck -D /dev/system/root 
e2fsck 1.46.3 (27-Jul-2021)
/dev/system/root is mounted.
e2fsck: Cannot continue, aborting.

А не поможет переименование файлов одного за другим из этого каталога в другой на той же фс и обратно в этот?

Нет.

Да, я понял. Чтоб процессы не прекращать

Вы чего-то не договариваете. Всё можно провернуть почти атомарно с минимальным downtime.

лучше применить не просто копирование

Там копий нет. Там есть rename в пределах одной fs. Правильнее делать hardlinks из новой директории, замораживать сервисы, rotate директории, отпускать сервисы, прибивать старую директорию. Но нужно хорошо знать логику сервисов чтобы правильно бороться с race conditions.

Возможно fsck.ext4 -fvD поможет. Забавно, в NTFS таких проблем нет, у меня 10+ летние разделы живут отлично, каждый по 2 терабайта.

Там копий нет. Там есть rename в пределах одной fs

Извиняюсь, невнимательно прочитал. Но моя идея про ссылки остается в силе, поскольку в предложенном Вами коде есть дубликат рабочего каталога «dir1.new», я его впопыхах принял за копию.

У ТС работа с каталогом медленно идёт, поэтому даже перемещение, а не только копирование может тормозить. Вот от этих тормозов, IMHO, я и предложил хак с ссылками ФС.

Ещё раз извините за невнимательность.

У ТС работа с каталогом медленно идёт, поэтому даже перемещение, а не только копирование может тормозить.

Всё правильно. Но как минимум один раз вычитать все эти 120Mb придётся так или иначе (пара секунд даже на старом добром HDD). Новый каталог будет настолько компактен насколько это возможно.

Да, согласен. Вы правы. Возьму на заметку.

Если тот каталог не является текущим ни у одного процесса, то даже mv в пределах файловой системы решит проблему.

Спасибо, теперь я знаю, что EXT* ещё более убогая и устаревшая ФС чем я думал. Проблемы на уровне древней и примитивной FAT.

Да уж, под хранилки не очень. А какая альтернатива?

XFS, ZFS, BFS, NTFS.

BFS - это BTRFS или что?

в них тоже есть свои плюсы и минусы :)
абсолюта светящего лучистым светом из-под небесья, чтоб все сразу так на ентую фс перешли, среди них нет.

Be File System. То что используется в Haiku. Использует B+ дерево для директорий.

Спасибо, теперь я знаю, что EXT* ещё более убогая и устаревшая ФС чем я думал. Проблемы на уровне древней и примитивной FAT.

Не всё так однозначно. Поведение директорий на ext4 в чём-то сравнимо с hash table: хотели бы Вы rehash’аться когда load factor падает ниже какого-то threshold после массового удаления элементов? Не уверен. В случае ext4 решение оставили за user space coders, и это правильно «я щитаю» - иначе бы возникали hiccups на пустом месте, в самые неожиданные моменты. Не надо недооценивать людей что за ext4 стоят.

XFS, ZFS, BFS, NTFS.

Я правильно понимаю что Вы глубоко знакомы со внутренностями всех этих fs types, и знаете как они себя ведут при удалении?

Если тот каталог не является текущим ни у одного процесса

Связи не вижу, от слова совсем.

Мы перенесли или сделали хардлинк всех файлов в соседний каталог (в рамках одной фс). Переименовали каталоги.

Если процесс который работает с файлами этого каталога открывает их по полному пути, то проблем нет.

А вот если у него этот каталог был текущим и ищет/открывает файлы в нем не по полному пути, то он это переименование каталогов не заметит и будет продолжать пытаться работать с файлами в старом (огромном) каталоге (даже после удаления этого каталога).

lsof/fuser это покажут.

Для BFS писал программу для чтения директорий. Там B+ дерево которое самобалансируется и в худшем случае заполнено наполовину. В XFS примерно тоже самое. Никаких фиксированных таблиц i-нодов, полностью динамическое выделение всех структур.

EXT* ещё более убогая и устаревшая ФС чем я думал. Проблемы на уровне древней и примитивной FAT.

В «древней и примитивной FAT» как минимум изкаропки уже отсутствует проблема ограничения по инодам. То есть это уже на голову более совершенная файловая система.

Это да.

Там B+ дерево которое самобалансируется и в худшем случае заполнено наполовину. В XFS примерно тоже самое. Никаких фиксированных таблиц i-нодов, полностью динамическое выделение всех структур.

Я не думаю что Вы понимаете о чём говорите.

А вот если у него этот каталог был текущим и ищет/открывает файлы в нем не по полному пути, то он это переименование каталогов не заметит и будет продолжать пытаться работать с файлами в старом (огромном) каталоге (даже после удаления этого каталога).

Good point. Если процесс держит cwd за хвост в форме fd - так и произойдёт.

65 тыc. кластеров это не ограничение?

Ну, а про fat32 написано, что там в каталоге может быть всего 65 тыс. записей (даже не файлов) https://answers.microsoft.com/en-us/windows/forum/all/what-is-the-maximum-num... На fat32 даже не протестить проблему, описываемую ТС.

mkdir new_folder

ln folder/* new_folder

mv folder old_folder ; mv new_folder folder

С учетом что изначально в топике речь про мульон файликов, вот на этом этапе folder/* может возникнуть проблема. Лучше эту строку заменить на find...

Их в основном удалили

Именно проблема в том, что файлов мало, но чтение каталога долгое, читается много пустых direntry.

Скорее, может возникнуть проблема с правами доступа. Я даже не знаю, есть ли команда, которая создаёт каталог и копирует все права с другого (включая acl, selinux).

Я даже не знаю, есть ли команда, которая создаёт каталог и копирует все права с другого (включая acl, selinux).

cp... ^c :)

в NTFS таких проблем нет

Прямо сейчас наблюдаю директорию размером 160 килобайт, в которой осталось всего 7 файлов. (Смонтировал диск под линуксом, смотрю размер в MC.) Возможно, там просто преимущественное кеширование директорий, которое компенсирует задержки?

На fat32 даже не протестить проблему, описываемую ТС.

Неоднократно наблюдал её на флешке. Поставил неправильный размер тома архиватору, насоздавал мелких файлов, упёрся в лимит, удалил их, после этого чтение пустой директории длится секунд 5-10. Когда это случалось в корне, лечил форматированием.