Почему монтирование происходит поверх существующего каталога?

Существующий каталог необходим в качестве точки монтирования .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Я нахожу это сбивающим с толку, поскольку он перекрывает существующее содержимое каталога. Существует два возможных содержимого каталога точек монтирования, которые могут неожиданно переключиться (для пользователя, который не выполняет монтирование).

Почему не mountпопадает во вновь созданный каталог? Именно так графические операционные системы отображают сменные носители. Было бы ясно, если каталог смонтирован (существует) или не смонтирован (не существует). Я уверен, что есть веская причина, но я пока не смог ее обнаружить.

Это случай утечки деталей реализации.

В системе UNIX каждый каталог состоит из списка имен, сопоставленных с номерами inode . Inode содержит метаданные, которые сообщают системе, является ли это файл, каталог, специальное устройство, именованный канал и т. Д. Если это файл или каталог, он также сообщает системе, где найти содержимое файла или каталога на диске. Большинство инодов являются файлами или каталогами. -iВариант lsсписок будет номера индексных дескрипторов.

Монтирование файловой системы берет индексный каталог и устанавливает флаг в копии ядра в памяти, чтобы сказать «на самом деле, при поиске содержимого этого каталога вместо этого смотрите на эту другую файловую систему» ​​(см. Слайд 10 этой презентации ). Это относительно просто, так как это изменение одного элемента данных.

Почему он не создает запись каталога для вас, указывая вместо этого на новый индекс? Это можно реализовать двумя способами, оба из которых имеют свои недостатки. Один из них - физически записать новый каталог в файловую систему, но это не даст результатов, если файловая система доступна только для чтения! Другой - добавить в каждый процесс листинга каталога список «лишних» вещей, которых на самом деле нет. Это неудобно и может привести к небольшому снижению производительности при каждой файловой операции.

Если вам нужны динамически созданные точки монтирования, automountсистема может сделать это. Специальные файловые системы без диска могут также создавать каталоги по желанию, например proc, sys, devfsи так далее.

Изменить: см. Также ответ на вопрос « Что происходит, когда вы« монтируете »существующую папку с содержимым?

Если в качестве точки монтирования mount(2) требовалось создать новый каталог, вы не могли монтировать что-либо в файловой системе только для чтения. Это было бы глупо, поэтому мы можем исключить это.

Если mount при необходимости создает новый каталог для точки монтирования, это будет странно. Это не так, как монтирование / размонтирование происходит постоянно, поэтому добавление дополнительной логики в ядро ​​для выполнения этих двух шагов с помощью одного системного вызова не будет важным ускорением. Просто оставьте это в пользовательском пространстве, чтобы сделать mkdir(2)системный вызов, если он этого хочет. В ответе Дмитрия указывается, что mount(2)выполнение обоих этих действий сделает его неатомарным. И вы хотите дополнительный аргумент mount(2)с режимом флагов , как open(2)требуется, для O_CREAT, O_EXCLи т.д. Это будет просто глупо по сравнению с позволяя пользовательское пространства сделать это.

Или, может быть, вы спрашивали о том, чтобы mount(8)(традиционная программа, mount(2)выполняющая системные вызовы) это делала? Это было бы возможно, но это уже идеально подходит mkdir(1)для этой работы, а дизайн Unix - это хорошие небольшие инструменты, которые можно комбинировать. Если вам нужен инструмент, который выполняет обе функции, то легко написать сценарий оболочки, чтобы построить этот инструмент из двух более простых инструментов. (Или, как прокомментировал muru, это udisksctlуже сделано , поэтому вам не нужно его писать.) Кроме того, обычный Linux mount(8)из util-linux поддерживает mount -o x-mount.mkdir[=mode]использование своего x-синтаксиса для параметров для пользовательского пространства, а не для параметров, передаваемых в файловую систему.

Теперь более интересный вопрос: почему в родительской файловой системе вообще должен быть каталог?

Как указывает ответ pjc50 (никакого отношения, даже если у него есть мои инициалы!), Отображение точек монтирования в списках каталогов потребует дополнительной проверки для каждого readdir().

Наличие точек монтирования существует в виде каталогов в директории, содержащей их (на родительской FS), это хороший трюк. readdir()не должен заметить, что это точка монтирования вообще. Это происходит только в том случае, если точка монтирования используется в качестве компонента пути. Разумеется, разрешение пути должно проверять таблицу монтирования для каждого компонента каталога пути.

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

1. mount успешно создает точку монтирования
2. mount пытается смонтировать новую файловую систему в этот каталог, но не удается
3. mount пытается удалить точку монтирования, но не удается

Система заканчивается побочным эффектом отказа mount.

Вот еще один:

1. umount успешно размонтирует файловую систему
2. umount пытается удалить точку монтирования, но не удается

Теперь должен umountвернуть успех или неудачу?

Еще один случай, который может произойти:

При загрузке базовый образ только для чтения загружается в корневой каталог. Таким образом, вы хотели бы переопределить его, когда вы хотите найти настоящий корень. Таким образом, вы можете себе представить, что системный вызов mount просто меняет точку roмонтирования на rw.

Давайте представим, что у вас проблема с файловой системой в корневой точке монтирования, и вы хотели бы попытаться исправить ее. С помощью mount overlap вы можете размонтировать файловую систему и использовать fsckпредоставленный базовый образ для ее решения.

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

Я тоже всегда удивлялся этому.

Простая обертка, такая как:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

сохраненный как исполняемый скрипт, названный mountв директории, переопределяющей /binв вашем PATH, должен позаботиться об этом, если это слишком беспокоит вас

(Перед запуском фактического mountдвоичного файла он создает каталог с именем после последнего аргумента mount, если такой каталог еще не существует.)

В качестве альтернативы, если вы не хотите, чтобы неудачные вызовы mountоболочки создавали каталоги, вы можете сделать:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }