Монотонный рост размера каталога 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. Если они верны для других файловых систем, зависит от их реализации.

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

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

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
источник