Монотонный рост размера каталога Linux / количества блоков
В Linux (возможно, в зависимости от размера блока файловой системы), когда я создаю каталог и stat
он возвращает размер 4096. Я могу создавать файлы в этом каталоге до определенного момента, не увеличивая воспринимаемый размер каталога (как сообщает stat
).
В какой-то момент, когда каталог заполняется многими файлами, размер каталога увеличивается (я не говорю о содержимом каталога, я говорю о блоках, используемых для представления самого каталога). Если файлы удалены, размер каталога остается прежним.
Вот быстрый пример:
[root@uxlabtest:/]$ mkdir test
[root@uxlabtest:/]$ stat test
File: `test'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fd00h/64768d Inode: 1396685 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:04.000000000 -0400
Change: 2011-07-26 14:06:04.000000000 -0400
Затем коснитесь группы файлов:
[root@uxlabtest:/]$ for i in `seq 1 10000`; do touch /test/$i; done
[root@uxlabtest:/]$ stat test
File: `test'
Size: 155648 Blocks: 312 IO Block: 4096 directory
Device: fd00h/64768d Inode: 1396685 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-07-26 14:06:04.000000000 -0400
Modify: 2011-07-26 14:06:56.000000000 -0400
Change: 2011-07-26 14:06:56.000000000 -0400
Затем удалите файлы:
[root@uxlabtest:/]$ rm -rf /test/*
[root@uxlabtest:/]$ stat test
File: `test'
Size: 155648 Blocks: 312 IO Block: 4096 directory
Device: fd00h/64768d Inode: 1396685 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2011-07-26 14:07:11.000000000 -0400
Modify: 2011-07-26 14:07:12.000000000 -0400
Change: 2011-07-26 14:07:12.000000000 -0400
Мои вопросы:
- Почему размер / количество блоков каталога монотонно увеличивается?
- Это функция базовой файловой системы или Linux VFS?
- Можно ли уменьшить размер каталога без удаления и повторного создания каталога?
- Бонусы: укажите мне исходный код ядра, в котором реализовано это поведение.
3 ответа
Вот ответы, которые верны для ext2/ext3/ext4. Если они верны для других файловых систем, зависит от их реализации.
- Пользователь user48838 ответил правильно. Больше файлов потребляют больше метаданных. Они размещаются в 4k кусках или в любом другом размере, определенном во время создания файловой системы.
- Да, это особенность / проблема реальной файловой системы
- В файловой системе ext3 это невозможно. Только воссоздав (пустой) каталог
- Исходный код находится здесь и в связанных файлах
Но тебе повезло. При воссоздании того же количества файлов, которые вы уже удалили, размер каталога останется прежним. Только когда вы добавите больше файлов, оно будет увеличиваться.
Приращения блока, которые вы видите, связаны с тем, как файловая система управляет хранением файлов и связанной с ними информацией об управлении файлами. В описанной вами ситуации это будет выглядеть с шагом 4 КБ, поэтому каждая "новая" / "уникальная" запись в файловой системе зарезервирует 4 КБ, независимо от того, заполняет ли фактический размер данных целые 4 КБ. Если связанные данные занимают все 4 КБ, тогда другой блок 4 КБ резервируется и заполняется по мере необходимости для сохранения всего потока / последовательности связанных данных.
В зависимости от "жесткого" и "мягкого" удалений, которые управляются файловой системой, удаление не может (как правило, не для "восстановить") немедленно освободить блоки, которые были зарезервированы. Некоторые файловые системы могут различать разные типы "удалений" и предоставлять соответствующие возможности управления блоками хранения.
То, как управление хранилищем подходит и реализуется, зависит от файловых систем, поэтому в ОС, которые поддерживают множественные / модульные файловые системы, ОС, как правило, предоставляет только "хуки" для интеграции файловой системы.
Добавление некоторого бессвязного комментария к хорошему ответу user48838:
Все это файл, включая каталоги. Чтобы хранить всю эту информацию о файле, вам нужно место.
Также было бы правильно показать, скажем, "64B используется" для небольшого каталога и фактически показать объем используемого пространства, но мы все равно будем использовать кратные 4K на диске, так что это было дизайнерское решение, чтобы просто показать количество используемого пространства.
С точки зрения дизайна FS, почему бы вам не потрудиться с расчетом того, что было использовано? Не обязательно. И тогда вам придется перемещать записи, чтобы не оставлять дыры... ick.
Когда происходит удаление, и размер директории уменьшается, чтобы вы могли освободить блок, все это управление должно произойти, прежде чем вы сможете это сделать. Зачем экономить несколько КБ? Скорее всего, вам придется расширить его позже в любом случае.
Оставьте читателю упражнение: подумайте, почему ваш каталог /lost+found создан пустым, но занимает 16 КБ (по крайней мере, на ext3).