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

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

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

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

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

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

Это отчасти по историческим причинам, а отчасти потому, что это имеет больше смысла.

Multics

Multics была первой операционной системой, которая представила иерархическую файловую систему, известную нам сегодня, с каталогами, которые могут содержать каталоги. Цитируя «Универсальную файловую систему для вторичного хранения» Р. К. Дейли и П. Г. Неймана:

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

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

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

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

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

Юникс

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

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

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

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

Windows

Windows ведет свое происхождение от двух линий: VMS , операционной системы, изначально разработанной для миникомпьютера VAX , и CP / M , операционной системы, разработанной для ранних микрокомпьютеров Intel.

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

CP / M был разработан для компьютеров с 64 КБ ОЗУ и дисководом гибких дисков, поэтому все было просто. Не было никаких каталогов, но ссылка на файл могла содержать указание диска ( A:или B:).

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

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

Не существует проблем безопасности за наличием единого дерева каталогов.

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

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

Обратите внимание, что названия букв дисков из MS-DOS, которые сохраняются в современной Windows, являются здесь красной сельдью. Названия букв дисков не являются лучшим представлением структуры файловой системы, которая имеет несколько корней. Они - соломенная реализация такой системы.

Правильно реализованная файловая система, которая поддерживает несколько корней, позволит произвольное именование томов, например dvdrom:/path/to/file.avi. Например, система избавит от смехотворных проблем с пользовательским интерфейсом, которые мешают Windows. Например, если вы подключите такое устройство, как камера, пользовательский интерфейс Windows Explorer заставит вас поверить, что есть устройство с именем «Камера» (или что-то еще), и у вас есть такой путь, как Computer\Camera\DCIM\.... Однако, если вы вырезаете и вставляете текстовую версию этого пути из Проводника, он фактически не работает, потому что некоторые из компонентов имени пути являются вымыслом пользовательского интерфейса, не известным базовой ОС. В правильно реализованной системе с несколькими корнями было бы хорошо: было быcamera:\DCIM\...путь, который признается равномерно на каждом уровне в системе. Более того, если вы перенесете старый жесткий диск со старого компьютера, вы не будете привязаны к какому-либо имени диска F:, а сможете назвать его как угодно old-disk:.

Итак, если бы Unix имел несколько корней в структуре файловой системы, это было бы сделано разумно, как это, а не как в MS-DOS и Windows с однобуквенными именами дисков. Другими словами, давайте сравним только схему Unix с хорошим многокорневым дизайном.

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

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

Более того, более гибко то, что тома не обязательно должны находиться на корневом уровне. Поскольку нет специального синтаксиса, который обозначает объем (это просто компонент пути), точки монтирования могут быть где угодно. Если вы приносите в трех старых дисках на ваш компьютер, вы можете иметь их /old-disk/one, /old-disk/twoи т.д. Вы можете организовать диски , однако вы хотите, как вы упорядочивать файлы и каталоги.

Могут быть написаны приложения, которые зависят от путей, и валидность путей может поддерживаться при переконфигурировании устройств хранения. Например, приложения могут использовать известные пути, такие как /var/logи /var/lib. Вам решать, находятся ли они на одном /var/logи /var/libтом же диске или на разных. Вы можете перенести систему в новую топологию хранения с сохранением путей.

Точки монтирования - это хорошая идея, поэтому Windows использовала их начиная с Windows 2000.

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

И * 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.

Я согласен с ответами выше, особенно с ответом Дуга О'Нила, но думаю, что все они что-то упускают, так же как и точные точки монтирования устройства, такие как MS-DOS «C:» или «A:».

Роб Пайк написал The Hideous Name о синтаксисе имен, но Расс Кокс выкинул его :

Пространства имен ... наиболее эффективны, когда новая семантика может быть добавлена ​​без добавления нового синтаксиса.

Единое пространство имен, в котором устройства могут быть произвольно смонтированы, обеспечивает действительно гибкие операции. Я регулярно использую /mnt/sdb1и /mnt/cdromвременно помещаю неиспользуемый в настоящее время диск или компакт-диск в общую файловую систему. Нередко наличие домашних каталогов на сервере NFS, так что независимо от того, на какой машине вы заходите, $HOMEвезде одинаково .

Это сводится к следующему: наличие специального синтаксиса для особых вещей накладывает определенные ограничения на то, что вы можете сделать. Если вы можете только монтировать неиспользуемый диск или CD или DVD, или сетевую файловую систему / «общий ресурс» на «E:» или «W:» или что-то еще, у вас гораздо меньше гибкости.

Это глупо. У Windows также есть единственная точка иерархии. Но это скрыто и нестандартно. Как большинство вещей окна.

В данном случае это концепция «Мой компьютер». Это эквивалент root (/) в Unix. Помните, что root - это концепция, которая существует в ядре. нравится тебе это или нет. Точно так же, как окна относятся к «Моему компьютеру». Конечно, вы можете смонтировать раздел root в unix, и это то, что делает большинство людей. И многие вещи будут искать конкретный путь для вещей (например, / etc /), но вы не ограничены этим. В любом случае, монтируйте ваши диски в / C: /. Вам не запрещено делать это в Unix.

C: \ не является корнем в windows, это точка монтирования одного раздела. Который ДОЛЖЕН быть на верхнем уровне «Мой компьютер». В то время как в Unix вы можете смонтировать раздел под любым другим деревом. Таким образом, в Linux вы можете смонтировать C: в /то время, как вы D: смонтированы в /mnt/d/... или даже также смонтированы, /но это сложно и зависит от поведения двух файловых систем при монтировании поверх уже смонтированного пути.

Таким образом, вы можете получить то же самое, что и с окнами, «заставив» себя следовать тем же ограничениям, которые окна произвольно накладывают на вас.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Тогда вам придется передать параметры монтирования в параметрах загрузки. так как у вас не будет / etc / ... но это также имитирует ограничения, которые накладывает Windows, как то, что он делает.

Причина, по которой Windows имеет буквы дисков, возможно, кроется в Microsoft и DOS. Присвоение букв съемным дискам было обычным явлением в системах IBM, поэтому Microsoft, возможно, просто действовала в соответствии с инструкциями IBM, копируя CP / M. И изначально у DOS не было каталогов.

Когда MS-DOS работал на компьютерах с одним или двумя съемными дисками и без фиксированных носителей, вам не требовалась файловая система с каталогами. С одним или, может быть, двумя 180-килобайтными дисками у вас никогда не было достаточно файлов, чтобы иметь большие проблемы с их организацией.

https://en.wikipedia.org/wiki/Drive_letter_assignment

На самом деле, Linux основан на Unix (или Unix, см. Обсуждение ), а Unix происходит из среды мэйнфреймов, где использование нескольких устройств было вполне очевидным. Монтирование устройств в одном дереве каталогов обеспечивает максимальную гибкость и не ограничивает количество устройств, к которым может обращаться операционная система.

С другой стороны, буквы DOS для накопителей являются хорошим дизайном для ПК с 1 или 2 дисководами и одним дисководом. Большая дискета 5,25 'всегда A:, маленькая 3,5' всегда B: и дисковод всегда C :. Вы всегда знаете, копируете ли вы файл на дискету или куда-нибудь на диск. Вам не нужна гибкость, если вы не можете физически подключить более 2-х дисководов гибких дисков и 2 (или 4) жестких дисков.

Дизайн DOS был более удобным для конечного пользователя, а дизайн Unix - удобным для администратора. Теперь буквы дисков - это бремя для Windows, пользователи больше полагаются на автоматическое открытие окна обозревателя со съемным содержимым диска, чем зная его букву ... Ubuntu делает то же самое.

Это не правда, на самом деле. Windows использует другую схему путей (ну, не то же самое)

«Буквы юнитов» - это только то, что легко запомнить пути, диски и разделы.

Пути ARC определяют путь к файлу в Windows (но они видны пользователю только при загрузке):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

В Windows NT нет никакой связи между дисками, разделами и буквами: вы можете «поместить» весь том в папку (например, c: \ myseconddisk может быть целым физическим диском!)

Я хотел бы отметить две вещи:

1. Жестким дискам в Linux фактически присваиваются буквы / имена, например / dev / sdb1. Но они могут быть смонтированы в любом месте для доступа из единственной / корневой структуры
2. Самая распространенная причина, по которой у людей (в том числе и у меня в прошлом) были отдельные диски в Windows, заключалась в том, чтобы иметь место для хранения документов, музыки, программ и т. Д., Чтобы в случае неизбежной переустановки или замены Windows, будь то обновление или вирус или сбой файловой системы, доступ к этим файлам все еще был. У меня нет этой проблемы в Linux - файловая система намного надежнее, ОС не ломается, если только по каким-либо прямым действиям или ошибкам с моей стороны (ох! Репортер, давайте попробуем!) И обновлениям НАМНОГО проще. И в редком случае мне пришлось переустанавливать, так как все программное обеспечение было доступно через репозитории или ppa, которые я добавил (и я мог легко скопировать мой домашний каталог с живого диска),

Если вы посмотрите назад в историю, вы также увидите, что Unix был запущен во времена 8-дорожечных ленточных систем для аудио и 9-дорожечных систем данных IBM (8 дорожек / 8 битов для данных, одна для контроля четности). Технически очень похоже.

В то время информация о расположении файлов хранилась в частях информации на ленте и определялась вперед и назад при чтении данных с ленты (например, файл с начальной позицией и конечной подписью); это также объясняет, почему у вас не было только одного FAT в начале диска - у вас было несколько, чтобы ускорить поиск. И если у вас было несколько дисков, они были связаны внутри / dev и через адрес файла, который вы перемещали между устройствами.

Я полагаю, у вас может быть мнение, что оно началось просто раньше и что решение в области MS Dos (CP / M) и более поздних версиях Windows NT просто связано с буквами дисков мэйнфреймов виртуальных машин, а не с одной точкой входа, потому что в то время, когда они выглядели более современные, объемы данных сегодня не существовали, и они не думали, что в конечном итоге вам не хватит букв дисков или что они будут перегружены.

9-Track-Drive и назначение буквы диска