Монотонный рост размера каталога Linux / количества блоков

8

В 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?
Можно ли уменьшить размер каталога без удаления и повторного создания каталога?
Бонусы: укажите мне исходный код ядра, где реализовано это поведение.

linux inode vfs

— loopforever
источник

Не совсем уверен, почему за это проголосовали. Это законные, четко выраженные вопросы с командами, заданными для воспроизведения сценария. Ответы на эти вопросы будут удовлетворять знания сообщества и было бы полезно где-то задокументировать.

— loopforever

9

Вот ответы, которые верны для ext2 / ext3 / ext4. Если они верны для других файловых систем, зависит от их реализации.

Пользователь user48838 ответил правильно. Больше файлов потребляют больше метаданных. Они размещаются в 4k кусках или в любом другом размере, определенном во время создания файловой системы.
Да, это особенность / проблема реальной файловой системы
В файловой системе ext3 это невозможно. Только путем воссоздания (пустой) директории
Исходный код здесь и в связанных файлах

Но тебе повезло. При повторном создании того же количества файлов, которые вы уже удалили, размер каталога останется прежним. Только когда вы добавите больше файлов, оно будет увеличиваться.

— mailq
источник

1

Одна вещь: «e2fsck -fD» должен сжать каждый каталог в файловой системе ext2 / 3. Это может делать то, что пожелает OP, хотя я подозреваю, что это медленно, и файловая система должна быть отключена. Это, вероятно, занимает больше времени, чем связывание каждого файла в новом каталоге и удаление старых.

— Акрамер

4

Приращения блоков, которые вы видите, связаны с тем, как файловая система управляет хранением файлов и связанной с ними информацией об управлении файлами. В описанной вами ситуации это будет выглядеть с шагом 4 КБ, поэтому каждая «новая» / «уникальная» запись в файловой системе зарезервирует 4 КБ, независимо от того, заполняет ли фактический размер данных целые 4 КБ. Если связанные данные занимают все 4 КБ, тогда другой блок 4 КБ резервируется и заполняется по мере необходимости для сохранения всего потока / последовательности связанных данных.

В зависимости от «жесткого» и «мягкого» удалений, которые управляются файловой системой, удаление не может (как правило, не для «восстановить») немедленно освободить блоки, которые были зарезервированы. Некоторые файловые системы могут различать различные типы «удалений» и предоставлять соответствующие возможности управления блоками хранения.

То, как управление хранилищем подходит и реализуется, зависит от файловых систем, поэтому в ОС, которые поддерживают множественные / модульные файловые системы, ОС, как правило, предоставляет только «хуки» для интеграции файловой системы.

— user48838
источник

1

Добавление некоторого бессвязного комментария к хорошему ответу user48838:

Все это файл, включая каталоги. Чтобы хранить всю эту информацию о файле, вам нужно место.

Также было бы правильно показать, скажем, «64B используется» для небольшого каталога и фактически показать объем используемого пространства, но мы все равно будем использовать кратные 4K на диске, так что это было дизайнерское решение, чтобы просто показать количество используемого пространства.

С точки зрения дизайна FS, почему бы вам не потрудиться с расчетом того, что было использовано? Не обязательно. И тогда вам придется перемещать записи, чтобы не оставлять дыры ... ick.

Когда происходит удаление, и размер директории уменьшается, чтобы вы могли освободить блок, все это управление должно произойти, прежде чем вы сможете это сделать. Зачем экономить несколько КБ? Скорее всего, вам придется расширить его позже в любом случае.

Оставьте читателю упражнение: подумайте, почему ваш каталог / lost + found создан пустым, но занимает 16 КБ (по крайней мере, на ext3).

— MikeyB
источник