Почему файловая система Linux спроектирована как единое дерево каталогов?

Question

Может ли кто-нибудь объяснить, почему Linux спроектирован как единое дерево каталогов?

В то время как в Windows у нас может быть несколько дисков, как C:\, и D:\, в Unix есть один корень. Есть ли какая-то конкретная причина?

Answer 1

Поскольку файловая система Unix появилась на много лет раньше Windows, можно перефразировать вопрос так: «Почему Windows использует отдельный идентификатор для каждого устройства?».

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

Предположим, у вас есть система, где ОС статична, и есть приложение с высокими требованиями к вводу/выводу. Вы можете смонтировать /usr только для чтения и поместить /opt (если приложение находится там) на SSD-диски. Иерархия файловой системы не меняется. В Windows это гораздо сложнее, особенно с приложениями, которые настаивают на размещении в C:\Program Files\

Answer 2

Отчасти это объясняется историческими причинами, а отчасти — тем, что так более разумно.

Мультикс

Мультиксбыла первой операционной системой, которая представилаиерархическая файловая системакак мы знаем его сегодня, с каталогами, которые могут содержать каталоги. Ссылаясь«Универсальная файловая система для вторичного хранения»RC Daley и PG Neumann:

В разделе 2 статьи представлена ​​иерархическая структура файлов, которая позволяет гибко использовать систему. Эта структура содержит достаточные возможности для обеспечения универсальности. (…)

Для простоты понимания файловую структуру можно представить как дерево файлов, некоторые из которых являются каталогами. То есть, за одним исключением, на каждый файл (например, каждый каталог) напрямую указывает ровно одна ветвь ровно в одном каталоге. Исключением является корневой каталог, или корень, в корне дерева. Хотя на него явно не указывает ни один каталог, на корень неявно указывает фиктивная ветвь, известная файловой системе. (…)

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

Как и во многих других аспектах, Multics стремился к гибкости. Пользователи могли работать в поддереве файловой системы и игнорировать остальное, и по-прежнему пользоваться каталогами для организации своих файлов. Каталоги также использовались для контроля доступа — атрибут READ позволял пользователям перечислять файлы в каталоге, а атрибут EXECUTE позволял пользователям получать доступ к файлам в этом каталоге (это, как и многие другие функции, сохранилось в unix).

Multics также следовал принципу наличия единого пула хранения. В статье этот аспект не рассматривается. Единый пул хранения хорошо соответствовал оборудованию того времени: не было никаких съемных устройств хранения, по крайней мере, таких, которые бы интересовали пользователей. Multics имел отдельный резервный пул хранения, но это было прозрачно для пользователей.

Unix

Unix во многом вдохновился Multics, но был нацелен на простоту, тогда как Multics стремился к гибкости.

Единая иерархическая файловая система хорошо подходила для Unix. Как и в случае с Multics, пулы хранения обычно не имели отношения к пользователям. Однако были съемные устройства, и Unix действительно предоставлял их пользователям черезmountиumountкоманды (зарезервированы для «суперпользователя», т.е. администратора).«Система разделения времени UNIX»Деннис Ритчи и Кен Томпсон объясняют:

Хотя корень файловой системы всегда хранится на одном и том же устройстве, не обязательно, чтобы вся иерархия файловой системы находилась на этом устройстве. Существует запрос системы монтирования с двумя аргументами: имя существующего обычного файла и имя специального файла, связанный с ним том хранения (например, пакет дисков) должен иметь структуру независимой файловой системы, содержащей собственную иерархию каталогов. Эффект монтирования заключается в том, что ссылки на ранее обычный файл ссылаются на корневой каталог файловой системы на съемном томе. По сути, монтирование заменяет лист дерева иерархии (обычный файл) на совершенно новое поддерево (иерархия, хранящаяся на съемном томе). После монтирования практически нет различий между файлами на съемном томе и файлами в постоянной файловой системе. Например, в нашей установке корневой каталог находится на небольшом разделе одного из наших дисковых накопителей, в то время как другой диск, содержащий файлы пользователя, монтируется последовательностью инициализации системы. Монтируемая файловая система создается путем записи в соответствующий ей специальный файл. Для создания пустой файловой системы доступна служебная программа, либо можно просто скопировать существующую файловую систему.

Иерархическая файловая система также имеет преимущество концентрации сложности управления несколькими устройствами хранения в ядре. Это означало, что ядро ​​было более сложным, но все приложения в результате были проще. Поскольку ядро ​​должно заботиться об аппаратных устройствах, а большинство приложений — нет, это более естественный дизайн.

Окна

Windows имеет две родословные:ВМС, операционная система, изначально разработанная дляВАКСминикомпьютер иКП/М, операционная система, разработанная для ранних микрокомпьютеров Intel.

VMS имела распределенную иерархическую файловую систему,Файлы-11. В Файлах-11,полный путь к файлусодержит имя узла, обозначение учетной записи на этом узле, имя устройства, путь к дереву каталогов, имя файла, тип файла и номер версии. VMS имел мощныйлогическое имяфункция, позволяющая определять ярлыки для определенных каталогов, чтобы пользователям реже приходилось беспокоиться о «реальном» местоположении каталога.

CP/M был разработан для компьютеров с 64kB RAM и дисководом, поэтому он пошел на простоту. Каталогов не было, но ссылка на файл могла включать указание на диск ( A:или B:).

КогдаMS-DOS2.0 ввел каталоги, он сделал это с помощью синтаксиса, который был совместим с MS-DOS 1, которая сама следовала CP/M. Таким образом, пути были корнем на диске с однобуквенным именем. (Кроме того, символ слэша /использовался в VMS и CP/M для запуска параметров командной строки, поэтому в качестве разделителя каталогов приходилось использовать другой символ. Вот почему DOS и более поздние версии Windows используют обратный слэш, хотя некоторые внутренние компоненты также поддерживают слэш).

Windows сохранила совместимость с DOS и подходом VMS, поэтому она сохранила понятие букв дисков, даже когда они стали менее актуальными. Сегодня, под капотом, Windows используетУНКпути (изначально разработанныйMicrosoft и IBM дляОС/2, родственного происхождения). Хотя это зарезервировано для опытных пользователей (вероятно, из-за веса истории), Windows позволяет монтировать черезточки повторной обработки.

Answer 3

Использование единого дерева каталогов не влечет за собой никаких проблем с безопасностью.

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

Это только часть гениальности, стоящей задизайн Unix.

Answer 4

И *nix, и Windows монтируют свои диски. В Windows они автоматически монтируются в точках монтирования, которые по умолчанию находятся в алфавитном порядке по возрастанию. Эти значения по умолчанию:

• A:и B:=> дискеты
• C:=> первый раздел первого жесткого диска
• D:=> следующий раздел или следующий жесткий диск или CD/DVD-привод, если других разделов нет.

Каждая из этих точек монтирования представляет собой каталог.

В *nix точки монтирования определяются пользователем. Например, у меня один раздел смонтирован как /, а другой как /home. Так что, /homeэто отдельный диск, это будет эквивалентно, скажем, E:в Windows.

В обоих случаях, Windows и *nix, точки монтирования являются отдельными каталогами. Единственное отличие в том, что в *nix эти отдельные каталоги являются подкаталогами /, в C:то время как в Windows каждая точка монтирования монтируется непосредственно под /, My Computerскажем, под .

С точки зрения пользователя, главное преимущество в том, что монтирования полностью прозрачны. Мне не нужно знать, что каталог /homeна самом деле находится на отдельном разделе. Я могу просто использовать его как обычный каталог. Вместо этого в DOS мне пришлось бы явно вызывать его по имени точки монтирования, скажемE:\home

Внешние диски монтируются примерно одинаково в обеих системах. Скажем, D:для Windows и /mnt/cdromдля Linux. Каждый из них — это каталог, я не вижу особой разницы. Когда вы вставляете CDROM в привод в Windows, диск монтируется так же, D:как в Linux.