Где хранятся записи файловых каталогов для подкаталогов?

Где хранятся записи файловых каталогов для подкаталогов?

Извините, если этот вопрос имеет точный дубликат где-то еще, но пока все ответы, которые я нашел на SE или других сайтах в целом, не отвечают конкретно на этот вопрос. Я изучаю операционные системы в своем колледже, и поэтому я довольно новичок в файловых системах в целом.

Я понимаю, что в большинстве файловых систем есть корневой каталог, содержащий записи каталога файлов. Эти записи содержат сопоставление имени файла с номером inode и имеют переменный размер по длине.

В соответствии сэтот ответ, я полагаю, эти записи хранятся в линейном порядке, как показано ниже:

Я могу полностью понять, что такое inode и как они сопоставляются с номерами блоков данных файла на физическом диске, используя записи их таблицы содержания (TOC).


Однако мой вопрос:Как и где хранятся записи файлового каталога подкаталогов?

Я бы предположил, что они либо хранятся в том же месте, что и корневой каталог, с некоторым смещением. Однако я не могу представить, как это смещение можно получить из inode.

Поэтому у меня есть ощущение, что записи каталогов подкаталогов на самом деле хранятся в области данных диска, а не вместе с записями корневого каталога.

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

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

Мы будем признательны за любую помощь.

решение1

Каталоги обычно реализуются как файлы. Они имеют inode и область данных, но, конечно, обычно доступны (по крайней мере, записываются) специальными системными вызовами. Некоторые системы позволяютчтениекаталоги с обычным read(2)системным вызовом (Linux этого не делает, FreeBSD делал, когда я последний раз проверял). Область данных файла каталога затем содержит записи каталога. На ext4корневой каталог также имеет inode, он зафиксирован на inode номер 2 (попробуйте ls -lid /).

Если каталог действует как файл, то легко выделять место для записей каталога и т. д., поскольку функции выделения блоков для файлов всегда должны быть там. Кроме того, поскольку они используют те же блоки данных, что и нужны, нет необходимости заранее выделять место между данными файла и списками каталогов.

Внутреннее устройство хранения записей каталога различается в разных файловых системах и, например, развивалось между ext2и ext4. Современные системы используют деревья вместо линейных списков для более быстрого поиска. Смотритездесь. Даже почтенныйФайловая система FATхранит каталоги как файлы, но, по крайней мере, в старых FAT корневой каталог является особым. (Структура записей каталогов в FAT, конечно, отличается от файловых систем Unix.)

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

Да. Но часто используемые записи каталога (или базовые блоки данных) в современных операционных системах, скорее всего, кэшируются.

Централизованное сохранение содержимого всех каталогов потребовало бы предварительного выделения большой области и все равно потребовало бы поиска на диске в области данных каталога.

решение2

Распространенное решение заключается в том, что некоторые из инодов в корневом каталоге указывают на записи, которые также являются каталогами. Во многих отношениях они похожи на файлы, но тип файла указывает файловой системе интерпретировать их как каталоги.

(В очень старых руководствах, например, для оригинального Unix, вам даже сообщат, что вы можете catтакже создать каталог. Но это, как правило, уже не так.)

Другими словами, каждый каталог представляет собой простой линейный список указателей inode. Некоторые из них указывают на конечные узлы в дереве каталогов (файлы), другие указывают на внутренние узлы (другой каталог). Единственное, что является особенным в корневом каталоге, это то, что он является своим собственным родителем, и что есть что-то внешнее по отношению к дереву, что говорит системе начать обход дерева отсюда.

Связанный контент