ハードリンクが同じファイルシステム内でのみ有効なのはなぜですか?


22

私はマーク・ベイツによるコマンドラインへのこのイントロを読んでいます。

最初の章で、彼はハードリンクがファイルシステムにまたがることができないことに言及しています。

ハードリンクについて注意すべき重要なことは、ハードリンクが現在のファイルシステムでのみ機能することです。別のファイルシステム上のファイルへのハードリンクを作成することはできません。これを行うには、シンボリックリンク、セクション1.4.3を使用する必要があります。

私が知っているファイルシステムは1つだけです。ルート(/)から始まるもの。ハードリンクがファイルシステムにまたがることはできないというこの声明は、私には意味がありません。

ウィキペディアのUnixファイルシステム上の記事では、どちらかの役に立ちません。

回答:


29

うまくいけば、あなたにとって意味のある方法でこれに答えることができます。Linuxのファイルシステムは、通常、ファイルを保存するさまざまな方法のいずれかでフォーマットされたパーティションで構成されています(お勧めです!)。あなたのシステムファイル、またはあなたの個人的なファイル...それらはすべてファイルシステムに保存されています。あなたが理解しているように見えるこの部分。

しかし、ハードドライブを複数のパーティションに分割する場合(Apple Pieが細かく分割されると考えてください)、または追加のハードドライブを追加する場合(おそらくUSBスティックですか?)議論のために、それらはすべてファイルシステムも持っています。

コンピューター上のファイルを見ると、パーティションのファイルシステム上のデータが視覚的に表示されています。各ファイル名は、iノードと呼ばれるものに対応します。これは、舞台裏でデータが実際に存在する場所です。ハードリンクを使用すると、同じiノードを指す複数の「ファイル名」(より適切な説明がないため)を使用できます。これは、それらのハードリンクが同じファイルシステム上にある場合にのみ機能します。代わりに、シンボリックリンクは「ファイル名」を指し、データを保持するiノードにリンクされます。私の粗雑なアートワークを許してください。

image.jpg             image2.jpg
          \           /
           [your data]

ここでは、image.jpgとimage2.jpgの両方がデータを直接指しています。どちらもハードリンクです。しかしながら...

image.jpg    <-----------  image2.jpg
           \ 
             [your data]

この(粗雑な)例では、image2.jpgはデータを指しておらず、データへのリンクであるimage.jpg ...を指しています。

シンボリックリンクは、ファイルシステムの境界を越えて機能します(USBスティックのように、ファイルシステムが接続およびマウントされていると仮定します)。ただし、ハードリンクはできません。他のファイルシステムの内容や、データが保存されている場所については何も知りません。

うまくいけば、これはより良い意味をなしてくれるでしょう。


ありがとう。異なるファイルパーティションが「ファイルシステム」と呼ばれることに気づきませんでした。
アントンパラス

1
パーティションでできることの1つはファイルシステムを置くことです。ファイルシステムを置くことができる場所やパーティションでできることは他にもありますが、最も一般的なオプションはその1つです。
-Jasen

10
「/」で始まるファイル階層が1つあります。1つ以上のファイルシステムがマウントされます
-mpez0

@ mpez0:たとえば、chroot(2)または実際のコンテナ化でさえ、複数の階層を持つことができます。
ケビン

@Kevin chrootは、プロセスとその子孫の階層の一部を分離しますが、親にはまだ1つの完全な階層があります。コンテナ化は、VMにどれだけ近いかに応じて実行できます。しかし、1つのコメントにどれだけ詳細を詰め込めますか?おかげで、
mpez0

23

ファイルシステムは、ファイルを整理するために、ディレクトリエントリの構成ディレクトリ構造によって構成されています。各ディレクトリエントリは、ファイル名をinodeに関連付けます。

ソフトリンクsymbolic)は、データを含まないディレクトリエントリであり、別のエントリ(同じファイルシステムまたは他のファイルシステム内のファイルまたはディレクトリ)を指しているだけです。また、先のとがったファイルを削除すると、シンボリックリンクは使用できなくなります。

ハードリンクは、ファイル名とiノード番号を含むディレクトリエントリです 。最後のハードリンクを削除すると、ファイルにアクセスできなくなります。

ソフトリンクとハードリンクの違い

結論:

inodeはファイルシステムのオブジェクトを表すために使用されるデータ構造であり、それはファイルシステムの内部だ、とあなたはを指すことはできませんiノード、別のファイルシステムの。

したがって、ハードリンクは同じファイルシステム内でのみ有効ですが、ソフトリンク(シンボリックリンク)は別のディレクトリエントリ(内部オブジェクトではなくファイルシステムのインターフェイス)を指すだけなので、ファイルシステムにまたがることができます


1
すてきな簡潔な答え。
ダブカット

別のファイルシステム(USBなど)が、ファイルシステム上でシンボリックリンクが接続されている同じ名前のファイルを持つ場合はどうなりますか?
ヨーゼフクリムク

@JosefKlimuk、ソフトリンクはパスを指しているとしましょう/mnt/myfile。別のファイルシステムをにマウントする場合/mnt/。ソフトリンクは、の下にマウントされたファイルシステムのエントリに解決されます/mnt/。したがって、USBデバイスからファイルシステムをマウントした場合/mnt、ソフトリンクはそのファイルシステム上のエントリに解決されます。
ファクンドビクター

2

ルートファイルシステムは、いくつかのファイルシステムで構成できます。/usr/local別のパーティションにマウントされ/home、ネットワークディスク上の別のパーティションにある場合があります。この場合、/usr/local/bin/git(たとえば)の外部へのハードリンクはfilesystemsにまたがるため/usr/local、の外部に作成されない場合があります

これは、iノードが//usr/localおよび/home(この例でも)に個別に割り当てられ、ハードリンクを作成するときに実際にiノードの追加名を作成するだけだからです。


2

ハードリンクには、ターゲットを存続させる効果があります。ハードリンクに到達できる限り、システムはそのターゲットが解放されないようにします。したがって、特定のiノードへのハードリンクを含む可能性のあるすべてのメディアは、システムがそのiノードへの参照が存在するかどうかを判断しようとするたびにマウントする必要があります。

通常、inodeの有効期間は、参照をスキャンするのではなく参照カウントを維持することによって決定されるため、リンクを使用する必要がなければ、相互にリンクを保持している2つ以上のファイルシステムを個別に使用できるように調整することが可能かもしれませんシステム間をブリッジし、いずれかでfsckを使用する必要がない場合。ただし、システムの1つでiノードのカウントが乱れた場合、そのシステムを再び使用できるようにする唯一の方法は、両方のファイルシステムの参照をスキャンできるfsck操作の形式を使用することです。その制約のため、2つの相互リンクされたファイルシステムを独立して使用できるようにすることは可能かもしれませんが、そうすることの利点はおそらくあまりにも制限されて価値がありません。


良い点ですが、正解には少し接線すぎます。
ジョー

@Joe:ファイルシステム間のハードリンクを許可すると、多くの技術的な困難が課せられますが、それらのほとんどは克服できます。そのため、そうすべきではない説得力のある理由があるのか​​という疑問が生じます。キープアライブの問題はあいまいに見えるかもしれませんが、他の問題とは異なり、そのようなリンクの使用に厳しいセマンティック制限を課すことで解決できます。
-supercat

いい視点ね。ファイルシステムは別のデバイスにマウントして変更できるため、iノードとリンクは「同期が取れていない」状態になります。すべてのファイルシステムにGUIDを設定し、リンクにそのGUIDを組み込んで、ファイルシステム間でiノードを追跡できます。FSに何らかのログがあり、マウントされている場合、ホストシステムはそれをスキャンする必要はありませんが、ログを読み取ってiノードのリンクの変更を「追いつく」ことができます(いつクリアしますか、しかし?)。一番下の行は、基礎となるFSを簡単な方法で変更する必要があり、互換性のあるファイルシステム間でのみ機能することです。
ロルフ

1

各ファイルシステム内のファイルを表すために使用される単一のiノード番号。iノード番号に基づくすべてのハードリンク。ファイルシステムリファレンスリンクはこちら

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