ハードリンクとは何かを知っていますが、なぜ使用するのですか?ハードリンクのユーティリティは何ですか?
ハードリンクとは何かを知っていますが、なぜ使用するのですか?ハードリンクのユーティリティは何ですか?
回答:
ハードリンクの主な利点は、ソフトリンクと比較して、サイズや速度のペナルティがないことです。ソフトリンクは、通常のファイルアクセスの上にある間接的な追加レイヤーです。ファイルを開くときにカーネルはリンクを逆参照する必要があり、これには少し時間がかかります。リンクは、リンクのテキストを保持するために、ディスク上の少量のスペースも必要とします。これらのペナルティは、ファイルシステムの構造そのものに組み込まれているため、ハードリンクには存在しません。
私がこれを見るのに知っている最良の方法は:
$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../
-i
オプションではls
、それはあなたを与える可能iノード番号ファイルのを。上記の例を準備したシステムで、たまたまiノード番号1069765のディレクトリにいましたが、特定の値は重要ではありません。特定のファイル/ディレクトリを識別する一意の値です。
これは、サブディレクトリに移動し、別のファイルシステムエントリを参照すると..
、以前取得したのと同じiノード番号を持っているということです。これは..
、MS-DOSおよびWindowsで発生するように、シェルがあなたのために解釈しているために発生していません。Unixファイルシステムで..
は、実際のディレクトリエントリです。前のディレクトリを指すハードリンクです。
ハードリンクは、ファイルシステムのディレクトリを結び付ける腱です。昔々、Unixにはハードリンクがありませんでした。Unixのオリジナルのフラットファイルシステムを階層ファイルシステムに変えるために追加されました。
(これについて詳しくは、「/」に「..」エントリがある理由を参照してください。)
Unixシステムでは、同じ実行可能ファイルでいくつかの異なるコマンドを実装することもある程度一般的です。任意のより多くのLinux上の場合ではないようですが、システム上で、私は過去に使用し、cp
、mv
およびrm
すべて同じ実行可能でした。あなたがそれについて考えるならば、それは理にかなっています:あなたがボリューム間でファイルを移動するとき、それは事実上コピーに続いて削除であるので、mv
すでに他の2つのコマンドの機能を実装しなければなりませんでした。実行可能ファイルは、呼び出された名前が渡されるため、提供する操作を把握できます。
別の例では、埋め込みLinuxesにおいて一般的であり、BusyBoxの実装単一の実行可能な多数のコマンドを。
ほとんどのファイルシステムでは、ユーザーはディレクトリへのハードリンクを作成できません。.
そして..
エントリは自動的に通常のカーネルの一部であるファイルシステムのコードによって管理されています。ディレクトリのハードリンクの作成方法と使用方法に注意を払わないと、深刻なファイルシステムの問題を引き起こす可能性があるため、制限が存在します。これは、ソフトリンクが存在する多くの理由の1つです。同じリスクはありません。
そのウィキペディアのページを読んだ後、あなたの質問が「なぜ私はそれらを使用するだろうか」である場合、あなたはハードリンクが何であるかを理解していません。
リンクは、ディスク上のブロックを指すディレクトリエントリです。つまり、システム上のすべてのファイルには少なくとも1つのリンクがあります。rm
ファイルの場合、実際のシステムコールはunlink()
です。ディレクトリエントリを削除します。ディスク上のブロックは変更されていませんが、リンクは削除されているため、ファイルはディレクトリリストから削除されています。
個人的にハードリンクを使用することはできませんが、システム全体にハードリンクがあります。例えば:
$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root 26292 2010-08-18 10:15 bzip2
あなたはそれを見ることができbunzip2
、bzcat
そしてbzip
全てが同じiノードを使用しています。本質的には、3つの名前を持つ1つのファイルです。ファイルのコピーを3つ持つことができますが、なぜですか?不必要にディスク領域を使い果たすだけです。
/bin
あります。これは混乱の原因の1つだと思います。なぜ実行可能ファイルがシンボリックリンクされ、時には-ハードリンクされるのですか?
さまざまな用途があります。それらを使用して、ファイルベースのロックを作成します。他のほとんどのシステムコールとは異なり、link(2)システムコールはアトミックです。
別の用途はrsnapshot内で、ハードリンクを使用してディスクスペースの量を削減するためにバックアップが時間をかけて行われます。ファイルが変更されていない場合、ファイルはファイルの古いインスタンスにハードリンクされ、変更されたファイルは新たにコピーされます。
また、サーバー上の構成ファイルをスワップアウトするために使用します:rm file.cfg && ln ~/tmp/file.cfg file.cfg
、その後〜/ tmp / *ファイルを安全に削除できます。
ln
とrm
だけではなくmv
?
既に存在するいくつかの良い議論に追加するには...
(inode, name)
以外の((だけでなく、限り、我々はディレクトリにhardlinkeできないようにすることで、サイクルを防ぐようペアはハードリンクを有することに、ファイルシステム内には余分なコストがないことを意味.
し、..
(これは他の誰かにLispのように感じ始めますか?))無料で入手できます。
ハードリンクの落とし穴のシナリオをカバーする必要があります。ハードリンクは、元のリンクファイルが存在する限り、名前や場所が異なる同じファイルになります。ファイルを「オリジナル」と考えるのは正しくありません。両方ともディレクトリエントリであり、両方(またはそれ以上)はすべて同等のピアです。長期間有効なファイルの場合、これは祝福かもしれませんが、ペアの1つが削除されてから作成された場合、同じ名前と内容であっても、ファイルは分離されます。
にリンクするハードリンク/foo/myfile
を作成したとします/repo/myfile
。どちらも同じファイルデータへのポインターです。一方を変更し、他方を変更します。しかし、それ/repo
がたまたまGitリポジトリを保持しているとします。含まmyfile
れていないブランチをチェックアウトすると、/repo/myfile
削除されます。この時点で、はペアのもう一方がリンク解除された時点でのの/foo/myfile
単純なコピーになり/repo/myfile
ます。レパートリーの変更をファイルするブランチを切り替えても気付かないことは簡単ですが、元のブランチをチェックアウトすると、新しいファイルが/repo/myfile
Gitによって作成されます。注意を怠ると、2つのファイルの内容が異なるのはなぜか疑問に思うかもしれませんが、ファイル間のハードリンク関係には名前がわからないため、簡単に理解できません。反対に、ソフトリンクは、この削除と作成のサイクルを通して存続します。
一方、ハードリンクを使用するソフトウェアはこれを鋭く認識しており、Gitはその好例です。Gitは、ファイルをコピーする代わりにデフォルトでハードリンクを使用するため、同じファイルシステム上のリポジトリをほぼ無料で複製します。Gitの場合、ハードリンクは完璧なユースケースです。そのオブジェクトとパックファイルは変更されないため、リポジトリの1つのクローンが他のクローンを変更することはありません(Gitは変更可能なファイルをハードリンクしないことを知っています)。予防措置なしに削除されます。どのファイルが「オリジナル」で、実際にファイルが含まれているかを追跡する必要はありません。ハードリンクはすべて同等のパートナーであり、ファイル全体を「含みます」。ここではソフトリンクは機能しません。
ハードリンクのもう1つの利点は、ファイルのコンテンツへのアクセスを中断せずにリンクを移動できることです。ソフトリンクでは、元のファイルを移動すると、そのファイルへのすべてのソフトリンクがぶら下がります。
一番下の行は、多くのユースケースでは、どちらのリンクタイプも同様に機能しますが、いずれかのタイプが有利であるということです。ここでの多くの回答で言及されている効率は、おそらく、最新のマシンやファイルシステムでは、小さな組み込みコントローラーのFLASHチップでファイルシステムを清掃しているのでなければ、ほとんど問題になりません。機能的な違いは、より重要であり、通常はエンジニアリング上の制約と究極の選択を指示します:
また、ファイルを削除するライブラリー呼び出しがunlink()
理由で呼び出されることを指摘する必要があります!すべてのディレクトリエントリは、そのiノードへの最初は単一のハードリンクです。