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

91

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

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

user2720323
источник
14
@terdon - Я думаю, он спрашивает о наличии единственного корневого каталога (/) по сравнению с DOS-стилем (C: \ D: \).
Иордания
27
Вы также можете (и обычно делаете) иметь несколько дисков в Linux. На самом деле, основной принцип тот же, C:и D:точки монтирования в Windows тоже. Эквивалент Windows /- My Computerвсе монтируется под этим.
Terdon
61
Я думаю, что более актуальным вопросом будет «почему операционная система НЕ имеет единственного корня»? (Ответом для DOS / Windows будет ошибка проектирования / неспособность планировать будущее / ненужное предположение)
JoelFan
21
Windows выбрала эту причудливую систему из-за MS-DOS, а MS-DOS следовала раннему прецеденту, установленному CP / M. MS-DOS была системой на основе дисковода гибких дисков (изначально A, и B: иногда, например, в системе с одним диском, A: и B: были одним и тем же диском, но двумя разными логическими дисками для операций подкачки / копирования) , Как и большинство людей, пострадавших от компьютеров MS-DOS, OP считает, что /в Linux это то же самое, что и C: в MSDOS / Windows, когда это не совсем то же самое.
Уоррен П
25
На самом деле, C:, D:и материал просто совместимость с DOS и Win32; Windows NT внутренне имеет некоторую UNIX-подобную иерархию объектов, где буквы дисков (и вообще материал Win32) являются просто символическими ссылками на «реальные» объекты ( c:\file.txtфактически \??\c:\file.txt, с \??\c:символической ссылкой, например \device\harddisk0\partition1). Смотрите, например, здесь
Matteo Italia

Ответы:

192

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

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

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

doneal24
источник
27
И на этот (риторический) вопрос есть ответ: традиция. Просто другая традиция, чем у Unix. Windows получает это от DOS, который получает это от CP / M-80, который следовал общей схеме многих миникомпьютерных и мейнфреймовых операционных систем. Названия дисков только сокращены от DISK0:или SY:до A:.
RBerteig
6
@RBerteig - возможно, традиция, особенно в случае с Windows, но Роб Пайк приводит довольно убедительный аргумент для схем именования в стиле Unix в The Hideous Name, pdos.csail.mit.edu/~rsc/pike85hideous.pdf
Брюс Эдигер,
13
Я полагаю, что начиная с Windows NT было возможно смонтировать устройство по заданному виртуальному пути в Windows, чтобы выполнить то же самое, что и в Unix, хотя это редко встречается на домашних ПК (несколько более распространено на серверах и в бизнес-приложениях). Вы можете рассмотреть это как оправдание Unix Way (tm), если хотите.
JSB ձոգչ
8
@BruceEdiger Я не собираюсь утверждать, что DOS был прав. Просто отметив, что существует контекст для того, почему Windows такая, какая она есть, и что это было не просто то, что MS вытащил из шляпы.
RBerteig
1
@BruceEdiger: Вау. Хорошая бумага. Это также один из немногих случаев, когда Пайк, безусловно, ошибался. (А именно, система обслуживания имен ARPANET не может масштабироваться. В наши дни мы называем это DNS, и она достаточно хорошо масштабируется. Основные понятия абсолютного иерархического пространства с полномочиями и делегированием остаются полностью неизменными). По общему признанию это - потому что сети не-IP, которые имеют отношение к почте, вымерли.
Кевин Кэткарт
87

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

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 разрешает монтирование через точки повторной обработки .

жилль
источник
3
Хотя это не стандартное поведение, в файловых системах NTFS Windows также может монтировать все хранилище под одним корнем: technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/… serverfault.com/questions / 24400 /…
герлос
3
Похоже, что важной частью является то, что MS-DOS 1.0 была основана на дискетах. В такой системе (а) это было важно знать , какая физический диск файлы были включены, и (б) A:и B:была порядочная конвенцией для различения ваших гибких дисков , если у вас два из них. Когда в MS-DOS 2.0 была добавлена ​​поддержка жесткого диска, C:обозначение диска обеспечивало обратную совместимость, рассматривая HD как одну БОЛЬШУЮ дискету.
user1024
5
На самом деле, изначально CP / M был рассчитан на 16 , а не 64 КБ ОЗУ. Размер 64 КБ, вероятно, позволяет приложениям иметь некоторую передышку; в то время как командный процессор (CCP) был перезаписан и при необходимости перезагружен, BIOS и BDOS постоянно оставались в памяти. Да, вот откуда берется BIOS - IBM не придумала этот термин! См. Википедия CP / M: Модель оборудования и Компоненты операционной системы . Помните, что 16 КБ - это всего лишь три плотно написанные страницы (70 строк × 80 символов / строка × 3 страницы = 16800 байт).
CVN
36

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

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

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

MSW
источник
28

Обратите внимание, что названия букв дисков из 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

Kaz
источник
6
Возможно, по совпадению, ваш «хороший дизайн с несколькими корневыми системами » очень похож на старую систему AmigaDOS , которая допускала произвольные имена томов, включая «назначенные» тома, которые ссылались на определенный каталог внутри другого тома. Вы даже можете (с соответствующим программным обеспечением ) иметь «виртуальные» тома, например, FTP:том, который позволяет вам получать доступ к файлам на любом FTP-сервере с таким путем, как FTP:hostname/path/to/file.
Илмари Каронен,
3
Это действительно не очень хороший ответ, так как он кажется чрезвычайно субъективным. Это довольно откровенное избиение Windows.
Рог
3
@Rig Хотя это может быть правдой, Windows заслуживает тщательного оскорбления за то, что все еще имеют эти названия дисков, начиная с MS-DOS. Это многопользовательская файловая система, с которой знакомы большинство пользователей, но мы не можем использовать ее в целях сравнения с однокорневой, потому что это пример такой системы.
Каз
3
@Kaz Я до сих пор нахожу этот ответ скорее напыщенным. Windows отличает файловую систему, но не делает ее неправильной, ужасной или преступлением против человечества. Вам не нравится, как вы имеете право. Microsoft даже не придумала эту схему, они позаимствовали ее у популярной системы того времени, но они должны поддерживать ее для разумного сопровождения устаревшим кодом.
Буровая установка
1
@Rig Sure; это не более ужасно, чем, скажем, получить следующий обед с помощью кремневого наконечника стрелы. Флинт стрелы были на самом деле современными в их расцвете . Ах, но, к сожалению, мы не можем на самом деле сказать это о DOS и буквах дисков, можем ли мы ... так много для аналогий.
Kaz
13

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

Тердон
источник
3
Из любопытства, знаете ли вы, что произойдет, если кто-то захочет создать 27 дисков в Windows? Как бы Windows назвала 27-й диск? : D
Джозеф Р.
2
Хахаха. Кажется, что Windows слишком скучна, чтобы делать это.
Джозеф Р.
3
Незначительный придирчивый: буквы дисков в Windows по умолчанию имеют возрастающий алфавитный порядок, но их можно и часто переименовывать.
RBerteig
3
@terdon: он просто монтирует диск в каталоге - точно так же, как вы делаете это в операционных системах POSIX.
Matteo Italia
3
@JosephR: В какой-то момент - я не уверен, когда, но, вероятно, NT - Windows получила возможность монтировать диски в каталогах, как это делает Unix. По умолчанию никто на самом деле этого не делает (что меня удивляет: с частотой переустановок nuke-and-pave, я думаю, что что-то аналогичное помещению / home на отдельный том сейчас бы стало популярным). Однако, если у вас закончились буквы дисков / цифры / символы, это то, что вам нужно сделать, если вы хотите добавить больше дисков в систему.
Ложный
10

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

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

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

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

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

Брюс Эдигер
источник
1
Вам не нужны символические ссылки для этого. Вы можете напрямую смонтировать раздел (или сетевое хранилище или любое другое) по любому пути, например, / usr / local - хотя это всегда сбивает меня с толку, когда я нахожу сеть, где / usr / local указывает на сетевое монтирование. Да, они существуют, и есть некоторая причина для этого: / usr / local - это одно из стандартных мест, где администратор может размещать вещи не у дистрибьютора ОС.
Кристофер Кройциг
@Christopher Creutzig - согласен, символическая ссылка не нужна для моего примера, я просто хотел добавить другой пример того, как гибкая схема именования может работать для вас. Возможно, это не самый лучший пример.
Брюс Эдигер
Посмотри на дурацкую паутину, кстати. proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html,
Каз
2
@Christopher Creutzig - я настроил / usr / local как сетевой диск в нескольких местах. «локальный» означает локальный для сайта, а не для машины.
doneal24
3
@ Каз, я считаю, что proto://бизнес - это прагматичная необходимость. Нельзя ожидать, что каждая часть программного обеспечения будет знать обо всех схемах URI. Таким образом, может быть полезно узнать, когда заканчивается идентификатор схемы и начинается остальная часть URI.
Адриан Ратнапала
5

Это глупо. У 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, как то, что он делает.

GCB
источник
4
У Windows есть единственная иерархия под капотом, и у нее даже есть точки монтирования, но она не использует их по умолчанию.
Жиль
1
@ Жиль не уверен, что я понимаю. Как присоединение каждого драйвера к корневому узлу «Мой компьютер» не использует его по умолчанию?
ГКБ
5
Это только презентация GUI. Пути к файлам не используются My Computer.
Жиль
3
My Computerявляется корневым узлом иерархии оболочки. он содержит диски, если они имеют букву диска , а также панель управления и любой подключенный Windows Phone. Иерархия оболочки использует PIDL вместо путей.
MSalters
4
@gcb: дело в том, что иерархия оболочки не может напрямую использоваться в «нормальных» приложениях. Вы не можете называть CreateFileпроходящие «Мой компьютер» или другие папки оболочки; это абстракция, понятная только для связанного с оболочкой кода, все вызовы ядра (и, следовательно, 90% приложений, поскольку управление файлами в большинстве языков реализовано в виде файловых API-интерфейсов ядра) ничего не знают об этом. Папки оболочки можно использовать только тогда, когда программы используют «стандартные диалоговые окна» (которые понимают пространство имен оболочки) и только когда выбранные файлы напрямую отображаются в «реальный» (= понятный ядру) путь.
Matteo Italia
5

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

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

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

david25272
источник
1
Это в лучшем случае неточно. CP / M предшествовал любой ОС Microsoft / IBM-PC на несколько лет (я полагаю, первоначальная идея IBM заключалась в том, чтобы использовать CP / M для своего «ПК», поскольку это был довольно хорошо установленный де-факто промышленный стандарт в то время, несмотря на тот факт , что различные CP / M системы могут быть несовместимы), и это едва ли оспаривается , что IBM-PC DOS была в значительной степени основана на 86-DOS , которая в свою очередь , был в основном источником-код , совместимый клон CP / M .
CVN
4

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

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

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

Дунайский моряк
источник
1

Это не правда, на самом деле. 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 может быть целым физическим диском!)

AndreaCi
источник
1
Пути ARC предназначены только для загрузки, для совместимости с некоторыми ПЗУ, когда NT был портирован на Alpha и MIPS. Когда система работает, она использует пути UNC.
ниндзя
0

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

  1. Жестким дискам в Linux фактически присваиваются буквы / имена, например / dev / sdb1. Но они могут быть смонтированы в любом месте для доступа из единственной / корневой структуры
  2. Самая распространенная причина, по которой у людей (в том числе и у меня в прошлом) были отдельные диски в Windows, заключалась в том, чтобы иметь место для хранения документов, музыки, программ и т. Д., Чтобы в случае неизбежной переустановки или замены Windows, будь то обновление или вирус или сбой файловой системы, доступ к этим файлам все еще был. У меня нет этой проблемы в Linux - файловая система намного надежнее, ОС не ломается, если только по каким-либо прямым действиям или ошибкам с моей стороны (ох! Репортер, давайте попробуем!) И обновлениям НАМНОГО проще. И в редком случае мне пришлось переустанавливать, так как все программное обеспечение было доступно через репозитории или ppa, которые я добавил (и я мог легко скопировать мой домашний каталог с живого диска),
Дрейк Кларрис
источник
2
Вы объединяете жесткие диски и файловые системы в своей первой точке. Если вы смонтируете / dev / sdb1 в какой-то момент файловой системы, вы сможете получить доступ к файлам на диске. Если вы откроете / dev / sdb1 напрямую, вы увидите необработанные дисковые блоки. Как правило, не очень полезно, особенно если вы используете зашифрованные файловые системы.
doneal24
Я пытался связать это так, чтобы пользователи Windows могли понять. C: в Windows тоже не жесткий диск, но все называют его так
Drake Clarris
1.Вы можете хранить свои файлы без букв. 2. В системах POSIX жесткий диск может быть разбит на разделы как единое целое без таблицы разделов, а на флэш-накопителе может быть таблица разделов. Оболочка даже содержит файл FS вместо портфеля, который знает только бог, кто придумал его. имя.
Behrooz
0

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

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

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

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

Питер
источник