既存のディレクトリ上でマウントが行われるのはなぜですか？

既存のディレクトリがマウントポイントとして必要です。

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

ディレクトリの既存のコンテンツをオーバーレイするため、混乱を招きます。（マウントを実行していないユーザーの場合）マウントポイントディレクトリには、予期せず切り替えられる可能性のある2つのコンテンツがあります。

mount新しく作成されたディレクトリではなぜ発生しないのですか？これは、グラフィカルオペレーティングシステムがリムーバブルメディアを表示する方法です。ディレクトリがマウントされている（存在する）か、マウントされていない（存在しない）かは明らかです。十分な理由があると確信していますが、まだ発見できていません。

これは、漏れた実装の詳細の場合です。

UNIXシステムでは、すべてのディレクトリはiノード番号にマップされた名前のリストで構成されます。iノードは、ファイル、ディレクトリ、特殊デバイス、名前付きパイプなどであるかどうかをシステムに伝えるメタデータを保持します。ファイルまたはディレクトリである場合、ディスク上のファイルまたはディレクトリの内容の場所をシステムに伝えます。ほとんどのiノードはファイルまたはディレクトリです。-iオプションlsの意志リストinode番号。

ファイルシステムをマウントすると、ディレクトリiノードを取得し、カーネルのメモリ内コピーにフラグを設定して、「実際、このディレクトリの内容を探すときは、代わりにこの他のファイルシステムを見てください」と言います（このプレゼンテーションのスライド10を参照）。これは、単一のデータ項目を変更するため、比較的簡単です。

代わりに新しいiノードを指すディレクトリエントリを作成しないのはなぜですか？それを実装する方法は2つありますが、どちらにも欠点があります。1つは、ファイルシステムに新しいディレクトリを物理的に書き込むことですが、ファイルシステムが読み取り専用の場合は失敗します！もう1つは、すべてのディレクトリリストプロセスに、実際には存在しない「余分な」もののリストを追加することです。これは手間がかかり、すべてのファイル操作で小さなパフォーマンスヒットが発生する可能性があります。

動的に作成されたマウントポイントが必要な場合、automountシステムはこれを実行できます。特殊な非ディスクファイルシステムはまた、例えば、意のままにディレクトリを作成することができproc、sys、devfsというように。

編集：コンテンツを含む既存のフォルダーを「マウントオーバー」するとどうなりますか？

マウントポイントとして新しいディレクトリを作成するmount(2) 必要がある場合、読み取り専用ファイルシステムの下には何もマウントできません。それは馬鹿げているので、それを除外することができます。

mountがオプションでマウントポイントとなる新しいディレクトリを作成した場合、それは奇妙です。マウント/アンマウントが常に発生するわけではないので、1つのシステムコールでこれら2つのステップを実行するためにカーネルに追加のロジックを配置しても、重要なスピードアップにはなりません。mkdir(2)必要に応じてシステムコールを行うために、ユーザースペースに任せてください。ドミトリーの答えmount(2)は、両方のことを行うと非原子的になると指摘しています。そして、あなたはに追加の引数をしたいと思うmount(2)ようにモードフラグを持つopen(2)ために、とりO_CREAT、O_EXCLそれはちょうど愚かなユーザ空間はそれを行うせることに比較されるなど、。

それとも、mount(8)（mount(2)システムコールを行う従来のプログラム）がこれを行うことについて尋ねていたのでしょうか？それは可能かもしれませんがmkdir(1)、仕事にはすでに完全に良いものがあり、Unixの設計はすべて、組み合わせることができる良い小さなツールに関するものです。両方を実行するツールが必要な場合は、シェルスクリプトを作成して、2つの単純なツールからそのツールを作成するのは簡単です。（または、muruがコメントしたように、udisksctlすでにこれを行っているので、書く必要はありません。）また、Linuxのmount(8)util-linuxからの通常は、ファイルシステムに渡すオプションではなく、ユーザースペースのオプションmount -o x-mount.mkdir[=mode]のx-構文の使用をサポートします。

さて、より興味深い質問：なぜ親ファイルシステムにディレクトリが必要なのでしょうか？

pjc50の答えが指摘しているように（彼は私のイニシャルを持っていても関係ありません！）、ディレクトリリストにマウントポイントが表示されるようにするには、everyの追加チェックが必要になりますreaddir()。

（親FS上の）それらを含むディレクトリ内にディレクトリとしてマウントポイントが存在することは、素晴らしいトリックです。 readdir()マウントポイントであることに気付く必要はありません。これは、マウントポイントがパスコンポーネントとして使用されている場合にのみ発生します。もちろん、パスの解決では、パスのすべてのディレクトリコンポーネントのマウントテーブルをチェックする必要があります。

既存のディレクトリにマウントすると、mount実質的にアトミックな呼び出しが行われます。少なくともユーザーの観点からは、成功または失敗します。mountマウントポイント自体を作成する必要がある場合、2つの障害点が発生し、クリーンロールバックを保証できなくなります。次のシナリオを想像してください。

1. mount マウントポイントを正常に作成します
2. mount そのディレクトリに新しいファイルシステムをマウントしようとしますが、失敗します
3. mount マウントポイントを削除しようとしますが、失敗します

システムは失敗の副作用で終わりmountます。

もう1つあります。

1. umount ファイルシステムを正常にアンマウントします
2. umount マウントポイントを削除しようとしますが、失敗します

さて、umount成功または失敗を返す必要がありますか？

発生する可能性がある別のケース：

ブートすると、基本的な読み取り専用イメージがルートディレクトリにロードされます。したがって、実際のルートをマウンドする場合は、オーバーライドする必要があります。したがって、mount syscallはroマウントポイントをにスワップするだけだと想像できますrw。

ここで、ルートマウントポイントにファイルシステムの問題があると想像してみましょう。修復を試してみたいと思います。マウントのオーバーラップにより、ファイルシステムをアンマウントし、fsck提供された基本イメージを使用して解決できます。

この機能は、roパーティションとパーティション間の変更を追跡するために強力なセキュリティが必要なシステムでも役立ちますrw。

私もいつもそう思っていました。

次のような単純なラッパー：

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

PATHをmountオーバーライドするディレクトリに名前が付けられた実行可能スクリプトとして保存されている/bin場合は、煩わしい場合はこれを処理する必要があります。

（実際のmountバイナリを実行する前にmount、そのディレクトリがまだ存在しない場合、最後の引数にちなんだ名前のディレクトリを作成します。）

あるいは、失敗したmountラッパーの呼び出しでディレクトリを作成したくない場合は、次の操作を実行できます。

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