Файловая система с «пузырьковым» размером каталога
В Баш/кш/Зш:
diff -u file.txt <(some command)
Конструкция <(some command)называется подстановкой процесса , и она делает вывод некоторой команды доступным, как если бы он был из файла, поэтому diffможет его прочитать. (Он устанавливает каналы из команды и расширяется до имени именованного канала или/dev/fd/N).
Точно так же >(some command)можно использовать для перенаправления записи в команды.
Современные файловые системы, такие как zfs/btrfs/bcachefs, на самом деле идут в противоположном направлении и разрешают/поощряют совместное использование экстентов между файлами. При этом понятие «сколько данных занимает каталог» становится менее четко -определенным (, хотя в некоторой степени это уже было верно из-за жестких ссылок ):с использованием рефлинков,можно создать каталог, который, по-видимому, содержит гораздо больше данных, чем может даже поместиться в файловой системе (, по крайней мере, насколько это могут понять простые инструменты анализа диска, такие как duили ncdu). Один из способов перефразировать вопрос: «сколько свободного места освободится, если этот каталог будет удален», что менее двусмысленно, но не так уж полезно, потому что, как только вы создадите снимок, у большинства каталогов теперь будет уникальный размер 0 (, потому что их данные также доступны через моментальный снимок ).
Я также столкнулся с проблемой:
- Трудно понять использование пространства в файловых системах, допускающих совместное использование данных
- Анализ использования пространства в больших файловых системах занимает слишком много времени. (Ввод-вывод)
По этой причине я создал btdu , профилировщик выборки использования диска, который решает эти проблемы для btrfs.
Что касается общей концепции «пузырькового» :я не уверен насчет других файловых систем, но это на самом деле похоже на внутреннюю работу btrfs, где есть одно главное корневое дерево (b -), которое рекурсивно ссылается на другие деревья. Когда любое дерево (многоуровневое )обновляется, новая копия записывается в другое место на диске (, отсюда COW-аспект btrfs )и родитель обновляется, чтобы указать на новую копию, которая в turn заставляет своего родителя обновляться таким же образом, и так далее до корневого дерева. (На практике реализация использует множество оптимизаций, чтобы сохранить свои инварианты, но сохранить разумную производительность.)