Я понимаю, что такое монтирование в Linux, и я понимаю файлы устройств. Однако я не понимаю, ЗАЧЕМ нам нужно монтировать.
Например, как поясняется впринятый ответ на этот вопрос, используя эту команду:
mount /dev/cdrom /media/cdrom
мы монтируем устройство CDROM /media/cdromи в конечном итоге можем получить доступ к файлам CDROM с помощью следующей команды
ls /media/cdrom
который выведет список содержимого CD-ROM.
Почему бы не пропустить монтаж вообще и не сделать следующее?
ls /dev/cdrom
И перечислите содержимое CDROM. Я ожидаю, что один из ответов будет: "Вот как устроен Linux". Но если так, то почему это было сделано именно так? Почему бы не получить доступ к каталогу /dev/cdromнапрямую? Какова настоящая цель монтирования?
решение1
Одна из причин заключается в том, что доступ на уровне блоков немного ниже того уровня, lsс которым можно было бы работать. /dev/cdrom, или dev/sda1это может быть ваш привод CD-ROM и раздел 1 вашего жесткого диска, соответственно, но они не реализуют ISO 9660 / ext4 - это просто RAW-указатели на те устройства, которые известны какФайлы устройства.
Одним из факторов, который определяет монтирование, является то, КАК использовать этот необработанный доступ — какая логика файловой системы/драйвер/модули ядра будут управлять чтением/записью или преобразовывать ls /mnt/cdromв какие блоки необходимо читать, и как интерпретировать содержимое этих блоков в такие вещи, как file.txt.
В других случаях этот низкоуровневый доступ может быть достаточно хорош; я просто читал и писал на последовательные порты, устройства USB, терминалы tty и другие относительно простые устройства. Я бы никогда не попытался вручную читать/писать с /dev/sda1, чтобы, скажем, отредактировать текстовый файл, потому что мне по сути пришлось бы заново реализовать логику ext4, которая может включать, среди прочего: поиск инодов файла, поиск блоков хранения, чтение всего блока, внесение изменений, запись полных блоков, затем обновление инода (возможно) или вместо этого запись всего этого в журнал — слишком сложно.
Один из способов убедиться в этом самостоятельно — просто попробовать:
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/dev— это каталог, и вы можете cdделать с ним lsвсе, что захотите. /dev/sda1— это не каталог; это особый тип файла, который ядро предлагает в качестве «дескриптора» этого устройства.
Видетьзапись в Википедии о файлах устройствдля более глубокого изучения.
решение2
По сути, если говорить проще, операционная система должна знать, как получить доступ к файлам на этом устройстве.
mountне только «предоставляет вам доступ к файлам», но и сообщает ОС о файловой системе диска, имеет ли он доступ только для чтения или для чтения/записи и т. д.
/dev/cdromэто низкоуровневое устройство, функции операционной системы не будут знать, как получить к ним доступ... представьте, что вы вставляете в него странно отформатированный CD-ROM (даже аудио-CD). Как узнать, lsкакие файлы (если они есть) есть на CD-ROM, не «монтируя» его предварительно?
Обратите внимание, что во многих ОС это происходит автоматически (даже в Linux в некоторых дистрибутивах и графических интерфейсах), но это не значит, что другие ОС не «монтируют» диски.
решение3
Я бы назвал это историческими причинами. Не то чтобы другие ответы были неправильными, но в этой истории есть еще кое-что.
Сравните Windows: Windows начиналась как однокомпьютерная, однопользовательская ОС. У этого единственного компьютера, вероятно, был один дисковод и один жесткий диск, не было сетевого подключения, USB, ничего. (Windows 3.11 имела собственные сетевые возможности;Windows 3.1 не.)
Настройки, изначально заложенные в Windows, были настолько простыми, что не было нужды в излишней изобретательности: просто монтируйте все (все два устройства) автоматически каждый раз, и не так много вещей могли пойти не так.
Напротив, Unix с самого начала создавался для работы в серверных сетях с несколькими пользователями.
Одним из решений дизайна Unix было то, что файловая система должна была выглядеть как единое целое для конечных пользователей, независимо от того, на скольких компьютерах были распределены физические диски, независимо от типа диска и независимо от того, с какого из десятков компьютеров пользователь будет получать к нему доступ. Логический путь к файлам пользователя оставался бы прежним, даже если бы физическое расположение этих файлов изменилось за одну ночь, например, из-за обслуживания сервера.
Они абстрагировали логическую файловую систему, пути к файлам, от физических устройств, на которых хранились эти файлы. Допустим, сервер A обычно размещает /home, но сервер A нуждается в обслуживании: просто отмонтируйте сервер A и смонтируйте вместо него резервный сервер B на /home, и никто, кроме администраторов, даже не заметит.
(В отличие от соглашения Windows о присвоении разным физическим устройствам разных имен — C:, D: и т. д. — что противоречит прозрачности, к которой стремился Unix.)
В такой обстановке вы не можете просто так монтировать все, что видите, как попало,
В большой сети отдельные диски и компьютеры постоянно выходят из строя. Администраторынуждатьсявозможность указать, что, где и когда монтируется, например, выполнить контролируемое выключение одного компьютера, в то время как другой компьютер прозрачно берет на себя размещение тех же файлов.
Вот почему с исторической точки зрения: Windows и Unix произошли из разных источников. Вы можете назвать это культурным различием, если хотите:
- Unix появился в среде, где администратору необходимо было контролировать монтирование; из десятков устройств хранения данных в сети администратор должен был решать, что, где и когда монтировать.
- Windows родилась в среде, где не было администратора и было только два устройства хранения данных, и пользователь, вероятно, знал, находится ли его файл на дискете или на жестком диске.
- (Разумеется, Linux изначально задумывался как ОС для одного компьютера, но с самого начала он был специально разработан так, чтобы максимально точно имитировать Unix на домашнем компьютере.)
В последнее время операционные системы стали сближаться друг с другом:
- В Linux добавлено больше функций для одного компьютера и одного пользователя (например, автоматическое монтирование), поскольку они стали часто использоваться в системах с одним компьютером.
- В Windows были добавлены новые функции безопасности, работы в сети, поддержки нескольких пользователей и т. д. По мере того, как сети становились все более распространенными, Microsoft начала создавать ОС также и для серверов.
Но все же легко сказать, что эти два явления являются результатом разных традиций.
решение4
В заголовке вопроса говорится:Зачем нужно монтировать в Linux?
Один из способов интерпретации этого вопроса:Почему нам нужно вводить явные mountкоманды, чтобы сделать файловые системы доступными в Linux?
Ответ: нет.
Вам не нужно явно монтировать файловые системы, вы можете сделать так, чтобы это делалось автоматически, и дистрибутивы Linux уже делают это для большинства устройств, так же как Windows и Mac.
Так что, возможно, вы не это хотели спросить.
Вторая интерпретация:Почему мыиногданеобходимо ли вводить явные mountкоманды, чтобы сделать файловые системы доступными в Linux? Почему бы не сделать операционную системувсегдасделать это за нас и скрыть от пользователя?
Вот вопрос, который я читаю в тексте вопроса, когда вы спрашиваете:
Почему бы не пропустить монтаж вообще и не сделать следующее?
ls /dev/cdrom
и указано ли содержимое компакт-диска?
Вероятно, вы имеете в виду: почему бы просто не заставить эту команду делать то, что
ls /media/cdrom
делает сейчас?
Ну, в таком случае /dev/cdromэто будет дерево каталогов, а не файл устройства. Так что ваш настоящий вопрос, похоже, таков: зачем вообще нужен файл устройства?
Я хотел бы добавить ответ к уже данным.
Почему пользователи видят файлы устройств?
Всякий раз, когда вы используете CD-ROM или любое другое устройство, на котором хранятся файлы, используется часть программного обеспечения, которая интерпретирует все, что находится на вашем CD-ROM, как дерево каталогов файлов. Оно вызывается всякий раз, когда вы используете lsили любую другую команду или приложение, которое обращается к файлам на вашем CD-ROM. Это программное обеспечение является драйвером файловой системы для конкретной файловой системы, используемой для записи файлов на ваш CD-ROM. Всякий раз, когда вы перечисляете, читаете или записываете файлы в файловой системе, работа этого программного обеспечения заключается в том, чтобы убедиться, что соответствующие низкоуровневые операции чтения и записи выполняются на соответствующем устройстве. Всякий раз, когда вы используете mountфайловую систему, вы сообщаете системе, какой драйвер файловой системы использовать для устройства. Независимо от того, делаете ли вы это явно с помощью команды mountили предоставляете ОС возможность сделать это автоматически, это необходимо сделать, и, конечно, программное обеспечение драйвера файловой системы должно быть там в первую очередь.
Как драйвер файловой системы выполняет свою работу? Ответ: он делает это, считывая и записывая данные в файл устройства. Почему? Ответ, как вы уже сказали: Unix был разработан таким образом. В Unix файлы устройств являются общей низкоуровневой абстракцией для устройств. Действительно специфичное для устройства программное обеспечение (драйвер устройства) для конкретного устройства должно реализовывать открытие, закрытие, чтение и запись на устройстве как операции над файлом устройства. Таким образом, более высокоуровневое программное обеспечение (такое как драйвер файловой системы) не должно знать так много о внутренней работе отдельных устройств. Низкоуровневые драйверы устройств и драйверы файловой системы могут быть написаны отдельно, разными людьми, если они договорятся об общем способе взаимодействия друг с другом, и именно для этого и предназначены файлы устройств.
Поэтому драйверам файловой системы нужны файлы устройств.
Но почему мы, обычные пользователи, можем видеть файлы устройств? Ответ в том, что Unix был разработан для использования программистами операционных систем. Он был разработан, чтобы позволить своим пользователям писать драйверы устройств и драйверы файловой системы. Фактически, именно так они и пишутся.
То же самое относится и к Linux: вы можете написать свой собственный драйвер файловой системы (или драйвер устройства), установить его и затем использовать. Это делает Linux (или любой другой вариант Unix) легко расширяемым (и это, по сути, причина, по которой Linux был создан): когда на рынке появляется какое-то новое оборудование или разрабатывается новый, более умный способ реализации файловой системы, кто-то может написать код для его поддержки, заставить его работать и внести его в Linux.
Файлы устройств упрощают эту задачу.