Work.Дыбр

[dzz]

Отсутствие ограничений суть зло.

Коллеги создали на ZFS директорию с 50 миллионами файлов. Задачка их удаления за разумное время оказалась крайне нетривиальной. Сейчас склоняюсь к мысли слить всё остальное на другой носитель и дропнуть FS.

Занятно, но на UFS такая ситуация практически невозможна - inode-ы кончились бы намного раньше.

Comments

[nine_k]

Отсутствие ограничений — это свобода. При неумелом употреблении опасна, как и многое другое.

А ведь кому-то, может, актуально иметь 50 миллионов файлов :) Кстати, за какое время они их столько создали?

[dzz.livejournal.com]

Это 50 миллионов никому не нужных транзакций зибеля ;)

За год с хвостом. Коллеги просто забыли, что их нужно чистить.

Собственно, началось всё с "ой, место на диске кончилось". du замер навеки. Методом исключения нашёл эту директорию с 60 гигами крошечных файлов. Написал скрипт параллелизации удаления. Он только список файлов 4 часа зачитывает. За двое суток в 4 потока удалилось около 3 миллионов. В общем, такими темпами будет шарашить недели две.

[nine_k]

Ого, всё, как в настоящей базе данных, включая даже метод "переписать нужное, а остальное грохнуть" :))

А du — это они погорячились, да %)

[dzz.livejournal.com]

По масштабам бедствия похоже ;)

[k001.livejournal.com]

Забавный use case для ZFS :)

[dzz.livejournal.com]

Угу, причём, неожиданный - мало кому в здравом уме придёт в голову ;)

Вообще, алгоритмы fast directory drop-а были бы полезны в fs, но специальных реализаций я что-то не помню (кроме фонового удаления в UFS, эффективного для умеренного количества больших файлов, но не в этом случае).

[dzz.livejournal.com]

В итоге таки убил dataset - это заняло всего 4 часа на освобождение блоков в пуле против пары-тройки недель на unlink-и.

Надо б, наверное, про этот usecase написать разработчикам, а то мужики-то и не знают ;)))