Зачем хранить собственные и родительские ссылки (. И ..) в записи каталога?

11

Рассмотрим файловую систему, нацеленную на некоторые встроенные устройства, которая делает чуть больше, чем хранит файлы в иерархической структуре каталогов. В этой файловой системе отсутствуют многие операции, которые вы можете использовать в таких системах, как Unix и Windows (например, ее права доступа совершенно разные и не привязаны к метаданным, хранящимся в каталогах). Эта файловая система не допускает никаких жестких или мягких ссылок, поэтому каждый файл имеет уникальное имя в строгой древовидной структуре.

Есть ли польза для хранения ссылки на себя и его родительский каталог в структуре данных на диске, который представляет каталог?

Большинство UNIX файловые системы имеют .и ..запись на диске. Интересно, почему они не обрабатывают их на уровне VFS (универсальный драйвер файловой системы). Это исторический артефакт? Есть ли веская причина, и если да, то какая именно, чтобы я мог определить, имеет ли это отношение к моей встроенной системе?

operating-systems filesystems

— Жиль "ТАК - прекрати быть злым"
источник

Я всегда полагал, что они были там только виртуально, чтобы программы могли легко получить доступ к текущему и родительскому каталогу. Интересный вопрос, а относится ли он сюда?

— Рафаэль

@ Рафаэль Я мог бы понять, если бы вы сочли мой вопрос слишком широким (→ «не реальный вопрос») или, возможно, «неконструктивным», потому что он несколько открытый. Но я не согласен с тем, что это не по теме: речь идет о дизайне файловой системы, как это не прикладная компьютерная наука? Если вы считаете, что это не по теме, пожалуйста, объясните свои аргументы на мета.

— Жиль "ТАК - перестань быть злым"

@ Рафаэль Я отредактировал свой вопрос, надеюсь, должно быть ясно, что моя точка зрения - это точка зрения разработчика встроенных ОС. Спасибо за ваши комментарии.

— Жиль "ТАК - перестань быть злым"

2

Наличие ссылок на родительский каталог имеет смысл для меня. Если у вас их нет, вам всегда нужно работать с целым списком каталогов. Так, например, /home/svick/Documents/должно быть представлено как { /, /home/, /home/svick/, /home/svick/Documents }. Если вы этого не сделаете, вы не сможете найти родительский каталог вообще (или это будет очень дорого). Это не только неэффективно, но и опасно. Если у вас есть два таких списка, которые перекрываются, они могут легко десинхронизироваться, если вы переместили какой-либо каталог.

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

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

— svick
источник

2

То же самое замечание: почему это происходит в каждой файловой системе, а не на уровне VFS? Большинство файловых систем Linux имеют .и ..записи.

— Жиль "ТАК - перестань быть злым"

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

— svick

1

@svick: Жиль не сравнивает наличие родительских ссылок с отсутствием родительских ссылок. Он сравнивает их наличие в реальной файловой системе с имитацией их промежуточным уровнем кода (vfs) между реальной файловой системой и пользовательским пространством.

— rgrig

2

Вы получаете меньше особых случаев. Во многих ситуациях VFS может обрабатывать «..», как и любое другое имя каталога.

— rgrig
источник

3

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

— Арьябхата

1

Да, но почему бы не справиться с этим на уровне VFS? С какой стати это связано?

— Жиль "ТАК - перестань быть злым"

Почему люди реализуют связанные списки с помощью стража, а не занимаются пустым списком в функциях добавления / удаления?

— rgrig

@rgrig: это происходит только тогда, когда интерфейс к рассматриваемой реализации связанного списка написан на языке, который исключительно плох при обработке индуктивных структур данных (C, Java и т. д.). Здесь эта проблема не актуальна, потому что уровень VFS не доступен напрямую с точки зрения пользователя.

— Стефан Гименес

@ StéphaneGimenez: Эта проблема является актуальной, так как VFS будет написан на C.

— rgrig

2

Единственная причина, которую я могу себе представить, заключается в следующем сценарии:

Первоначальная реализация файловой системы существовала в том же формате каталогов, но понятия путей к файлам и подкаталогов в то время не рассматривались (см . Файловая система Unix PDP-7 ).
Тогда люди думали, что разрешение пути и подкаталоги будут полезны!
Чтобы сохранить некоторую обратную совместимость со старыми реализациями, было решено, что .и ..будет храниться на диске, как и любой другой каталог.

Так что, может быть, у нас остались эти бесполезные артефакты, просто ради обратной совместимости с 40-летним программным обеспечением? Достоверный сценарий?

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

— Стефан Хименес
источник

1

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

Что касается общей необходимости .и ..как бы вы выразили относительные пути без них? По крайней мере, ..это необходимо для путей, которые покидают текущее поддерево. Если вам не нужны такие пути (может быть, дерево является примитивным способом кодирования прав доступа?), Вам не нужно ...

— Рафаэль
источник