Linuxはシンボリックリンクをどのように処理しますか?


11

あるプロセスがシンボリックリンクを読みたいときに何が起こっているのですか?読み取りまたは書き込みプロセス中にシンボリックリンクが変更された場合はどうなりますか?

例:2つの巨大な同様の100Gファイル/mnt/1とがあり/mnt/2ます。/mnt/1symlinkから入手できます/home/user/file。一部のプログラムAが読み取りを開始します/home/user/file。そして、しばらく後に何かがからリンクを変更/mnt/1する/mnt/2が、Aそれでもファイルを読んでいます。

プログラムは絶対パスをキャッシュしますか?

シンボリックリンクが変更されたか、何も起こらなかったように正常に動作するため、失敗してエラーになりますか?

/home/user/fileブロックデバイスにリンクされている場合(たとえば、2つの複製されたiSCSIディスク)は異なりますか?

回答:


9

シンボリックリンクは、ファイルシステム内の実際のファイル(inode)の名前を指します。システムがそのシンボリックリンクを解決して実際のファイルを見つけて開くと、ファイルのiノードが検出されて使用されます。その時点で、ファイルに到達するために使用したパスは重要ではありません。OSがキャッシュしないものは、iノードによってファイルから読み取られます。私が理解しているように、ハードリンクを介してファイルの読み取りを開始し、そのハードリンクを削除することができます(ファイルが他の場所からリンクされている限り)。ファイルが解決されている限り、問題は発生しません(名前文字列-> inode)。


4
ファイルへのリンクをすべて削除しても、ファイルを開いた後は引き続き読み続けることができます。これが、Windowsでのように再起動せずにパッケージをアップグレードできる理由です。プログラムが実行されていても、プログラムの実行可能ファイルをrmできるからです。
psusi

1
@psusiデータとiノードがまだ存在し、それ以上ポイントされていないことはわかっていますが、ファイルが削除されると、システムはディスク上のその場所を自由に上書きできますよね?それで、問題の100GBファイルのように、ファイルが大きすぎてファイルキャッシュに収まらない場合、最後に到達する前にファイルの一部が上書きされるとどうなりますか?重要なシステムファイルはキャッシュに読み込まれてそこに保持されるため、これは問題ではありませんが、100 GBは十分に大きいため、問題になる可能性があると思います。
ケビン

2
ケビン、ファイルを使用する最後のプロセスが終了するまで、ファイルはディスクから削除されませんでした。procで現在使用中のすべてのファイルをいつでも見つけることができます。しかし、あなたの答えは私の質問を説明しているようです。ありがとう。
ラッシュ

2
この回答は、シンボリックリンクにターゲットファイルの名前が含まれているという重要なポイントを逃しています。
キーストンプソン、

6

シンボリックリンクが含まれている小さなファイルです場所をそれはシンボリックリンクだことを示すディレクトリエントリ内のフラグと、対象ファイルの(すなわち、パスとファイル名)。

シンボリックリンクを開くと、OSはその場所をたどってターゲットファイルを見つけます。ターゲット自体シンボリックリンクである場合、それは同様にその位置を次の(1)(2)のファイルへの地点までありません FinalFileと呼びます)。次に、OS はFinalFileiノードを取得します(inodeには変更時間などのメタデータが含まれ、ファイルのデータへのポインターも含まれます)。最後に、FinalFileのiノードが開かれます。これ以降、プロセスはそのiノードを使用してファイルの読み取り/書き込みを行います。結果として、シンボリックリンクの名前またはパスの変更、シンボリックリンクの削除、FinalFileのパスまたは名前の変更、あるいは削除FinalFileを(3)プロセスに影響を与えません。同じiノードからまだ読み取り中です。

ほとんどの場合、シンボリックリンクのファイルデータ操作はFinalFileに影響します(たとえば、シンボリックリンクの読み取りと書き込みはFinalFileの読み取り/書き込みになります)例外があります。readlink()システムコールはシンボリックリンク自体の内容を読み取ります。

一方、ファイルのメタデータ操作(名前の変更や削除など)は通常、シンボリックリンクに影響します。ただし、ここにも例外があります。lstat()システムコールはと似stat()ていますが、FinalFileではなくシンボリックリンク自体に関する情報を返します(2)。


(1)レベルの数には制限があり、シンボリックリンク内の場所が相対パスの場合、状況は少し複雑になります。

(2)詳細については、symlink(7):シンボリックリンクの処理を参照してください。man 7 symlink

(3)rmコマンドまたはunlink()システムコールは、ファイルを物理的に削除しません。ファイルのiノードを指すディレクトリエントリを削除します。ファイル自体た場合にのみ削除され、両方の a)にそのiノードaとbを参照してください。これ以上のディレクトリエントリ(ハードリンク)がないが)何のプロセスがファイルオープンを持っていません。


1

これはLinuxにはほとんど透過的であり、運用システムよりも、使用しているファイルシステムとの関連性がはるかに高くなります。

これは通常のファイルではなく、非常に小さなファイルでもあります。たとえば、シンボリックリンク自体をVFATパーティションにコピーするだけでは作業シンボリックリンクを作成できないためです。これは、ファイルシステムによって直接記録されるためです。

ハードリンクへのシンボリックリンクの違いは、ハードリンクのようにデータセクターをポイントするのではなく、ハードリンクへのアポイントメントであることです。

例:

テスト1:

echo 'data' >file.txt

これにより、セクター10〜20を指すハードリンクfile.txtが作成されます*(*説明のための数字のみ)。

テスト2:

ではどうすればよいですか?

ln file.txt file_2.txt

これにより、セクター10〜20(file.txtと同じ)を指すハードリンクfile_2.txtが作成されたため、file.txtを削除してもセクター10〜20は予約されており、file_2.txt内のデータを表示できます... 。(file.txtとfile_2.txtはどちらもオリジナルと同じです)

テスト3:

ln -s file.txt file_sym.txt 

シンボリックリンクfile_sym.txtをハードリンクfile.txtに向けたため、file_sym.txtにアクセスしようとすると、file.txtが表示されますが、file.txtを削除すると、file_symはターゲットを検出できなくなります。

これらはファイルシステム、たとえばLinuxのext4モジュール(またはカーネルでコンパイルされている場合)によって管理されています。Linuxや他のUnixを使用しているかどうかは関係ありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.