Зачем нам монтировать на Linux?


67

Я понимаю, что такое монтирование в Linux, и я понимаю файлы устройства. Однако я не понимаю, ПОЧЕМУ нам нужно монтировать.

Например, как объясняется в принятом ответе на этот вопрос , с помощью этой команды:

mount /dev/cdrom /media/cdrom

мы монтируем устройство CDROM /media/cdromи в конечном итоге можем получить доступ к файлам CDROM с помощью следующей команды

ls /media/cdrom

который будет перечислять содержимое CDROM.

Почему бы вообще не пропустить монтаж и сделать следующее?

ls /dev/cdrom

И есть содержимое CDROM в списке. Я ожидаю, что один из ответов будет таким: « Так устроен Linux ». Но если так, то почему это было разработано таким образом? Почему бы не получить доступ к /dev/cdromкаталогу напрямую? Какова реальная цель монтажа?


2
Вы также можете быть заинтересованы в Проблемы с пониманием концепции монтажа
PM 2Ring

23
Обратите внимание, что практически все операционные системы «монтируются». Это просто прозрачно в большинстве случаев. Когда в Windows вы выбираете «безопасно удалить» для pendrive, вы фактически выполняете размонтирование, после того как система автоматически смонтировала его. Linux просто не изолирует пользователя настолько далеко от процесса, так что в результате вы можете «настроить» его больше - скажем, раздел umsdos ничем не отличается от vfat, но если вы используете его mount -t umsdosдля монтирования, у вас есть все права доступа Linux, права собственности, специальные файлы, fifos и т. д. Если вы ведете mount -t vfatсебя как обычный раздел Windows.
SF.


7
«Я понимаю, что такое монтирование в Linux, и я понимаю файлы устройств». Видимо нет;)
Легкость гонок с Моникой

5
Why not access the /dev/cdrom directory directly?Потому что это не каталог.
Брэндон

Ответы:


67

Одна из причин заключается в том, что доступ на уровне блоков является немного более низким уровнем, чем тот, с lsкоторым можно работать. /dev/cdromили dev/sda1может быть дисководом компакт-дисков и разделом 1 вашего жесткого диска, соответственно, но они не поддерживают стандарт ISO 9660 / ext4 - это просто RAW-указатели на те устройства, которые называются файлами устройств .

Одной из вещей, которые определяет mount, является КАК использовать этот необработанный доступ - какие модули логики / драйвера / ядра файловой системы будут управлять чтением / записью или преобразованием, ls /mnt/cdromв какие блоки нужно читать, и как интерпретировать содержимое этих файлов. блокирует в такие вещи, как file.txt.

В других случаях этот доступ низкого уровня может быть достаточно хорошим; Я только что прочитал и записал на последовательные порты, USB-устройства, терминалы tty и другие относительно простые устройства. Я бы никогда не пытался вручную читать / писать из / dev / sda1, скажем, для редактирования текстового файла, потому что мне бы пришлось в основном переопределить логику ext4, которая может включать, среди прочего: поиск файловых инодов, поиск блоки хранения, прочитайте полный блок, внесите мои изменения, напишите полные блоки, затем обновите inode (возможно), или вместо этого запишите все это в журнал - слишком сложно.

Один из способов убедиться в этом - просто попробовать:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devэто каталог, и вы можете cdи lsвсе, что вам нравится. /dev/sda1не является каталогом; это специальный тип файла, который ядро ​​предлагает в качестве «дескриптора» для этого устройства.

Посмотрите запись в Википедии о файлах устройств для более глубокого рассмотрения.


4
Я закрываю некоторые детали, потому что я думаю, что плохие вещи произойдут, если вы просто начнете писать в любые данные, хранящиеся в / dev / sda1, и, таким образом, я предполагаю, что есть какие-то профилактические меры или, возможно, абстракция, которые не позволят вам перезаписывать вещи. Но если подытожить, если бы вы точно знали, как и где записать на диск, вы можете сделать это вручную /dev/sda1. Обратите внимание, что некоторые инструменты взаимодействуют напрямую с необработанными дисками, такими как swapon/swapoffи dd.
Эрик

4
Просто добавьте немного больше, монтирование инициализирует файловую систему и, таким образом, также активирует целый уровень автоматической обработки операций ввода / вывода, который прозрачен для пользователя (например, кэширование файлов в ОЗУ, постановка в очередь операций, удержание состояний открытых файлов). и так далее). Вот почему вы также должны размонтировать файловую систему правильно, чтобы избежать повреждения (или, по крайней мере, синхронизировать его). Монтирование присутствует на всех обычно используемых платформах, а не только в Linux. Если монтирование автоматически выполняется в среде рабочего стола (KDE или gnome), оно так же скрыто, как и в окнах MS.
Орион

6
@Ehryk (3 комментария) единственная предупреждающая мера в типичной системе Linux - это права доступа к файловой системе - иными словами, вам нужно использовать учетную запись root для записи в файл устройства. Если вы это сделаете, вы можете, cat >/dev/sda1как душе угодно , и Linux не остановит вас. (Излишне говорить, что это полностью повредит файловую систему.)
Дэвид З

5
@psusi Вы не могли бы сделать это на Windows 95, правда. Но он присутствовал (и хорошо скрыт) в MS DOS и Windows NT. Ваша современная Windows-основанная Windows, безусловно, позволяет вам монтировать и размонтировать разделы по желанию (даже в папки на других разделах, и даже в несколько папок одновременно) - просто обычно по умолчанию монтируются все неизвестные разделы на буквы дисков. Вы также можете получить доступ к устройству, не монтируя его, используя его полный путь (очень похожий на путь unix), но только если он не заблокирован - что, конечно, есть, если он подключен в данный момент.
Луан

3
@Luaan & psusi Psusi имеет на это право. Но почти для всех целей и задач эффект для вызывающей стороны Win32 API в основном одинаков. (Для соответствия Posix существует даже эмуляция семантики монтирования.) Win9x действительно имеет концепцию монтирования, потому что он все еще работает поверх DOS. Поддержка FAT была встроена в DOS как собственный обработчик, чем-то похожий на то, как ядро ​​NT обрабатывает его. Но CDROM и сетевые файловые системы должны были быть смонтированы. (Вспомните MSCDEX для CD. Это обеспечивало обработчик файловой системы ISO / RockRidge и монтировало его на букву диска).
Тонни

20

По сути, операционной системе необходимо знать, как получить доступ к файлам на этом устройстве.

mount не только «дает вам доступ к файлам», но и говорит операционной системе о файловой системе диска, если она доступна только для чтения или для чтения / записи и т. д.

/dev/cdromэто низкоуровневое устройство, функции операционной системы не знали бы, как получить к ним доступ ... представьте, что вы вставили в него странно отформатированный компакт-диск (даже аудио компакт-диск), как lsопределить, какие файлы (если они есть) находятся на CD-ROM без «монтажа» это в первую очередь?

Обратите внимание, что это происходит автоматически во многих ОС (даже в Linux в некоторых дистрибутивах и графических интерфейсах), но это не означает, что другие ОС не «монтируют» диски.


8

Для согласованности

Представьте, что у вас есть несколько разделов на первом жестком диске в вашей системе. Например, /dev/sda2. Позже вы решаете, что диск недостаточно велик, поэтому вы покупаете второй и добавляете его в систему. Внезапно, это становится, /dev/sdaи Ваш текущий двигатель становится /dev/sdb. Ваш раздел сейчас /dev/sdb2.

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

Тем не менее, монтирование позволяет вам использовать ту же точку монтирования для этого переименованного диска. Вы должны будете отредактировать, /etc/fstabчтобы сообщить вашей системе, что (например) /media/backupтеперь /dev/sdb2вместо этого, но это только одно редактирование

Обратите внимание, что современные дневные системы еще проще. Вместо того, чтобы ссылаться на устройство как /dev/sda2или /dev/sdb2, они имеют UUIDS, которые выглядят аналогично c5845b43-fe98-499a-bf31-4eccae14261bили могут иметь более удобные ярлыки, например, backupкоторые могут использоваться для ссылки на устройство при монтаже. Таким образом, имя устройства не меняется при добавлении нового устройства, что делает администрирование еще проще:

# mount LABEL="backup" /media/backup

Для безопасности

Требуя подключения устройства, администратор может контролировать доступ к устройству. Устройство может быть удалено, когда оно отключено, но не во время использования (если только вы не хотите потерять данные). Если вы (были) пользователем Windows, помните маленький зеленый значок в области уведомлений, который говорит вам, что можно безопасно извлечь USB-накопитель? Это Windows монтирование и размонтирование флешки для вас. Так что принцип не просто Unix / Linux.


На самом деле универсальные идентификаторы - это UUID, а не GUID от Microsoft.
Руслан

@ Руслан - так оно и есть! У меня была голова MS в то время. Большое спасибо - я изменил это.
garethTheRed

6

Я бы назвал это историческими причинами. Не то, чтобы другие ответы были неправильными, но есть немного больше истории.

Сравните Windows: Windows начиналась как однопользовательская ОС для одного компьютера. Этот единственный компьютер, вероятно, имел одну флоппи-дисковод и один жесткий диск, без сетевого подключения, без USB, без ничего. (Windows 3.11 имела собственные сетевые возможности; Windows 3.1 не имела .)

Тип установки Windows был настолько прост, что не нужно было фантазировать: просто каждый раз монтируйте все (все два устройства) автоматически, не так уж много (и не так уж много) может пойти не так.

Напротив, Unix был создан для работы в серверных сетях с несколькими пользователями с самого начала.

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

Они абстрагировали логическую файловую систему, пути к файлам от физических устройств, которые хранили эти файлы. Скажем, сервер A обычно является хостом / домом, но сервер A нуждается в обслуживании: просто размонтируйте сервер A и установите вместо него сервер резервного копирования B в / home, и никто, кроме администраторов, даже не заметит.
(В отличие от соглашения Windows о присвоении разных физических устройств разных имен - C:, D: и т. Д. - которое работает против прозрачности, к которой стремилась Unix.)

В такой обстановке вы не можете просто монтировать все в поле зрения волей-неволей,

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

Вот почему с исторической точки зрения: Windows и Unix происходили из разных областей. Вы можете назвать это культурной разницей, если вам нравится:

  • Unix родился в среде, где администратору нужно было управлять монтированием; из десятков устройств хранения в сети администратор должен решить, что и где смонтировано.
  • Windows родилась в условиях, когда не было администратора и только два устройства хранения, и пользователь, вероятно, знал бы, находится ли их файл на дискете или на жестком диске.
  • (Конечно, Linux зародился как однокомпьютерная ОС, но с самого начала он был явно разработан, чтобы максимально точно имитировать Unix на домашнем компьютере.)

В последнее время операционные системы приближаются друг к другу:

  • Linux добавил больше однопользовательских и однопользовательских программ (например, автомонтирование); как это часто используется в настройках одного компьютера.
  • Windows добавила больше безопасности, сети, поддержки нескольких пользователей и т. Д .; По мере того, как сетевые технологии становились все более распространенными, Microsoft также начала создавать ОС для серверов.

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


1
Дело не только в этом. Устройства являются низкоуровневыми абстракциями для использования драйверами файловой системы (и, возможно, другим системным программным обеспечением). Unix была разработана, чтобы быть операционной системой для программистов операционной системы. Например, программисты этих драйверов файловой системы. Вот почему эти низкоуровневые абстракции открыты для пользователя.
reinierpost

5

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

Специальные файлы - это файлы, которые представляют устройства. Одна из идей, на которых был построен Unix, - это все файлы. Это упрощает многие вещи, например, взаимодействие с пользователем - это просто чтение и запись файла на устройстве tty, которое является специальным символьным файлом. аналогично проверка на наличие поврежденных блоков, разбиение или форматирование диска - это просто файловые операции. Не имеет значения, является ли диск mfm, ide, scsi, fiberchanel или чем-то еще, это просто файл.

Но, с другой стороны, вы можете не захотеть иметь дело с целым диском или разделом, а только с файлами, и во многих случаях больше файлов, чем уместится на диске. Итак, у нас есть точки крепления. Точка монтирования позволяет вам поместить весь диск (или раздел) в каталог. Еще во времена Slackware, когда жесткий диск хорошего размера составлял пару сотен МБ, обычно использовался компакт-диск как / usr, а жесткий диск для /, / usr / local и swap. Или вы можете поставить / на один диск и / домой на другой.

Теперь я заметил, что вы упомянули о монтировании вашего CD в / media / cdrom, что удобно для компьютеров с одним приводом CDROM, но что, если у вас их больше одного? где вы должны смонтировать второй? или третий? или пятнадцатый? вы, конечно, можете использовать / media / cdrom2 и т. д. Или вы можете смонтировать его в / src / samba / resources / windows-install или / var / www, или там, где это имеет смысл.


Я думаю, что OP имел в виду, почему бы не пропустить все mountцеликом и просто взаимодействовать /dev/cd0, /dev/cd2, /dev/sda1, /dev/sda2напрямую - у каждого уже есть определенный «каталог».
Эрик

1
Вы правы, но действительно ли вы найдете / dev / sdb9 / share / doc / package / README хорошим путем? даже d: / share / doc / package / README лучше, но / usr / share / doc / package / README имеет семантику! это значение точки монтирования.
Хильдред

3
Я подозреваю, что семантическое использование появилось позже как полезный побочный продукт крайней необходимости «вставить некоторый код между системой каталогов и указателем в виде необработанного файла на устройство», потому что использовать cd / ls / nano / все остальное гораздо проще, чем raw write:, не dd if=/file of=/dev/sda2 bs=4096 skip=382765832 count=84756говоря уже об ассоциированном обновлении inode / FAT / journal.
Эрик

(некоторые мазохисты linux, вероятно, хотели бы / dev / sdb9 как рабочие каталоги, я уверен)
Ehryk

2
Мой первый компьютер запускал cp / m на 2 8 "дискетах. Он вообще не поддерживал подкаталоги. Один каталог на диск. Путь был похож на b: name.ext. Идея семантического именования уже была установлена. Даже ленточные системы используемые имена файлов. UNIX уже отклонил идею использования букв дисков для точек монтирования. Кстати, @Ehryk, знаете ли вы, что вы можете монтировать диск в каталоге не только в Windows, но и в DOS? Я сделал это в MS-DOS 5 кроме того, когда я ищу страницу
справочника,

5

Заголовок вопроса спрашивает: зачем нам монтировать на Linux?

Один из способов интерпретации этого вопроса: зачем нам нужно вводить явные mountкоманды, чтобы сделать файловые системы доступными в Linux?

Ответ: мы не делаем.

Вам не нужно явно монтировать файловые системы, вы можете сделать так, чтобы это делалось автоматически, и дистрибутивы Linux уже делают это для большинства устройств, как это делают Windows и Mac.

Так что это, вероятно, не то, что вы хотели спросить.

Второе толкование: почему нам иногда нужно вводить явные mountкоманды, чтобы сделать файловые системы доступными в Linux? Почему бы не заставить операционную систему всегда делать это для нас, и скрывать это от пользователя?

Это вопрос, который я читаю в тексте вопроса, когда вы спрашиваете:

Почему бы вообще не пропустить монтаж и сделать следующее

ls /dev/cdrom

и есть ли содержимое CD-ROM в списке?

Предположительно, вы имеете в виду: почему бы просто не сделать эту команду

ls /media/cdrom

делает сейчас?

Ну, в этом случае, /dev/cdromбудет дерево каталогов, а не файл устройства. Таким образом, ваш реальный вопрос, по-видимому, таков: зачем вообще файл устройства?

Я хотел бы добавить ответ к уже заданным.

Почему пользователи видят файлы устройств?

Каждый раз, когда вы используете компакт-диск или любое другое устройство, на котором хранятся файлы, используется программное обеспечение, которое интерпретирует все, что находится на вашем компакт-диске, как дерево каталогов файлов. Он вызывается всякий раз, когда вы используете lsлюбую другую команду или приложение, которое обращается к файлам на вашем компакт-диске. Это программное обеспечение является драйвером файловой системы для конкретной файловой системы, используемой для записи файлов на компакт-диск. Всякий раз, когда вы перечисляете, читаете или записываете файлы в файловой системе, задача этого программного обеспечения состоит в том, чтобы обеспечить выполнение соответствующих низкоуровневых операций чтения и записи на соответствующем устройстве. Всякий раз, когда вы mountиспользуете файловую систему, вы указываете системе, какой драйвер файловой системы использовать для устройства. Делаете ли вы это явно сmountили оставьте это для ОС, чтобы сделать это автоматически, это нужно будет сделать, и, конечно, программное обеспечение драйвера файловой системы должно быть там в первую очередь.

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

Таким образом, драйверы файловой системы нуждаются в файлах устройства.

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

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

Файлы устройства делают это проще.


1
очень хорошо объяснил
Шайлендра

4

Многие механизмы баз данных могут работать напрямую с необработанными дисками или разделами. Например, MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Это позволяет избежать издержек при прохождении драйверов файловой системы, когда все, что действительно нужно ядру БД, - это один огромный файл, который заполняет диск.


3

Поскольку /dev/cdromэто устройство, в то время как /media/cdromэто файловая система . Вам необходимо смонтировать первый на втором, чтобы получить доступ к файлам на CD-ROM.

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

Все операционные системы делают это - однако некоторые (например, Windows, когда он монтирует CD-ROM D:) делают это прозрачно. Linux оставляет это вам, чтобы вы могли лучше контролировать процесс.


2
Я должен не согласиться с вашей формулировкой. /dev/cdromэто файл устройства (который имеет специальные возможности, позволяющие нам легко осуществлять ввод-вывод с / на связанное устройство). /media/cdromэто каталог, но по сути это другой файл (помните, что в Linux все является файлом, включая каталоги). Теперь, когда мы mountимеем специальную возможность просматривать содержимое файла устройства как файловую систему. Мое понимание последнего послания от чтения ответов выше.
Greeo

@Greeso: я поддерживаю мой ответ.
Легкость гонки с Моникой

0

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

Таким образом, в фундаментальном смысле пользовательский интерфейс для мультимедиа должен обрабатывать два вида потенциальных событий монтирования одинаково, и у компьютеров нет хорошего способа управлять сетевыми подключениями настолько интуитивно, как это возможно для сетевых подключений с другими пользовательскими интерфейсами к компьютерам, такие как смартфоны, планшеты и носимые компьютеры, у которых нет возможности вставки физических носителей в устройства. (Обратите внимание, насколько ужасен интерфейс iPhone для переключения SIM-карт, один из видов физических устройств iOS, вставленных в них.

Также обратите внимание, что другие популярные подходы к пользовательским интерфейсам для этого типа физического блока (например, Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) и Mac OS X v10.9 (Mavericks)) сталкиваются с теми же проблемами и использовать дополнительные диалоговые окна графического интерфейса пользователя, чтобы разобраться в возможной путанице (например, Windows 8 обычно настраивается для запроса каждого нового вставленного компакт-диска, должен ли он быть подключен в качестве файловой системы, музыкального носителя или, если необходимо, коллекции видео MP4 ). Нет никаких причин, по которым любой из этих пользовательских диалогов не может использоваться с Linux или другими UNIX.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.