他の人は、順方向シンボリックリンクについてどのように考えているのか疑問に思います。安全ですか？良い練習？頼る？ [編集] - 問題空間に近すぎるため、用語が理解できない可能性があるため、順方向シンボリックリンクを定義していません。
ルートと/ usrをマージしようとする試みはほとんど失敗したため（bin、lib、lib64の2つの別々のディレクトリを削除したディストリビューション（cygwinを除く、ディストリビューションと見なす場合）はわかりません）、ディストリビューションでは主にOpenSUSEを使用します。マージを実装する方法は、/ usrにバイナリをインストールすることです。多くのプログラムには多くのプログラムへのパスがハードコーディングされているため、/bin/がおそらく最も一般的であるため、インストールパッケージは/bin/prog -> /usr/bin/progにシンボリックリンクを配置します。これは順方向リンクではありません（この用語は親ディレクトリからサブツリーへのスーパーバイザとして定義できますが、これは明らかに多くの環境では問題ではありません）。
セキュリティと信頼性に関連する環境では、 1) バックアップとリカバリ時間とバックアップスペースを最適化するために、異なるツリーを異なるデバイスに配置します。 2）消去または破損したパーティション関連の問題が含まれています。 3）攻撃でハードリンクファイルやその他のメカニズムを使用できる特定のセキュリティ攻撃を無効にします。理由1に関しては、特定のディレクトリとサブディレクトリにはしばしば小さな変更（/ var）がたくさんあります。一部は頻繁に変更されません（/etc、/bin、/sbin）。一部は毎日変更される可能性があります（/home）。同様に使用されるディレクトリを1つのパーティションにグループ化すると、頻繁に変更されないパーティションのバックアップが減り、頻繁に変更されるディレクトリをRAMディスクまたはSSDに配置することが適切です。
ただし、パーティションが異なる理由は、順方向接続方式が安全であるか「ベストプラクティス」であるか（またはそうでないか）とは何の関係もありません。より明確に説明するには、/usr/{{s,}bin,lib64}の下のディレクトリを指す/bin、/sbin、および/lib64にシンボリックリンクを配置します。 "/usr"が別々のパーティションの場合は、/{{にリンクを指定します。 s,}bin,lib64/ は「安全ではなく」実際に悪い管理慣行です。 /usr を保持するディスクがいくら安定していても何らかの理由でマウントできない場合 - ライブラリはバイナリルートディレクトリ /{ にリンクされています。 bin,sbin,lib64}は価値のないシステムが起動しなくなります。
私は個人的に3つの状況を経験しました。 「マウント」バイナリは/usr/bin/mountにあり、シンボリックリンクは/bin/mountにあり、最新のインストーラは複数のライブラリに再構成され、/lib64ライブラリのシンボリックリンクは/usrを指します。まだインストールされていない/ lib64および最近の失敗モード：プログラムが誤った番号のlibバージョンをロードするのを防ぐために、ライブラリのバージョン番号をバイナリとライブラリに入れます。
通常、この組み合わせは機能します。主な問題は、インストールされるまで同伴ディレクトリに含まれるバージョン番号がわからないことです。通常の操作中に、ルートディレクトリのファイルは/usr/lib64のファイルと動的にリンクできます。 / usrがマウントされていない場合は、/ lib64の同じ名前のライブラリとの接続を試みて失敗する可能性があります。最後のケースは、同じ名前のライブラリを/usr/lib64から/lib64にコピーして、ルートパーティションの/usrへのシンボリックリンクを元に戻そうとした副作用です。残念ながら、同じパッケージの新しいバージョンに更新すると、新しいバージョンはルートディレクトリにコピーされません。 /usr/lib64 コピーの時刻/日付スタンプが /lib64 の時刻/日付スタンプより古い場合、これをキャプチャする簡単な方法はありません。
リンカーユーティリティ「ldd」は、ファイル名ベースのバージョンを持つ必須ライブラリを表示しますが、含まれているバージョンについてはすぐにはわかりません。これらの追加作業は、まだマウントされていないファイルシステムに他のファイルシステムをマウントして起動するために必要なリソースを配置することによって発生します。
私は誰もこれが悪い慣行であると指摘していない理由の1つが、誰もそう簡単に失敗することができるものを実装すると信じていないか、新しく作成された理由が「バグ」ではないと信じていたからだと強く考えます。 - ハードディスクから直接高速ブートがサポートされなくなったように（元のSuSEインストーラの以前のバージョンで設定された）、パーティション分割はサポートされなくなりました（システム開発者はより速いブート時間をお勧めしますが）。
残念ながら、新しいデスクトップ開発者は/usr/binファイルを/binに安全にマージすることなく、以前の管理方法を無視しています。いくつかの理由は、ルートに十分なスペースがない可能性があるためです！
cygwinのようにマージしない理由が見つかりません。 （単に/bin @ / usr / binをマウントします。シンボリックリンクは含まれていません）。これは、他の問題を抱えている行動/出来事を「受け入れる」ことをやや仮定的なアドバイスによく似ています。
最後の仕上げの文：「私は保守的すぎるのですか？それとも、正方向リンクが重要な文書の「ベストプラクティス」領域にあると見なされますか？」
新しい失敗方法が登場するにつれて、私はこの問題について過度に保守的な可能性を考慮しなくなりました。私はこれが管理的な「ベストプラクティス」と見なすことができる方法がないと思います。
答え1
与えられたバイナリがどこにあるべきか（/または/ usr）を見つけることは、不必要に複雑で目的がないという主張があります。システムはしばらく/usrなしで起動できなかったため、両方のディレクトリを維持する理由はありません。
バラよりhttp://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge詳細については。
答え2
シンボリックリンクを広く（そして注意して）使用するより良い理由は...
シンボリックリンクはファイルシステム（階層データベース）用であり、外部キーはリレーショナルデータベース用です。
「前方」および「後方」シンボリックリンクを慎重に使用すると（以前はこのように言及されていませんが）、/etc、/bin、/lib、および/sbinを含むディストリビューションを設計することができます。内容は、/usr/etc、/usr/bin、/usr/lib、および/usr/sbinへのシンボリックリンクです。 /usrディレクトリのいくつかのバージョンは、/initrd（RAMディスクの初期化）などのどこかにインストールできます。その後、ファイルシステムはシンボリックリンクを慎重に作成および削除して、特定の時間に使用されている各ファイルのバージョンを管理できます。
子犬Linux他のディストリビューションで使用同盟そしてオブファイルシステムはこの概念のバリエーションを実装します。
分散ソースオペレーティングシステムは、永続ストレージの「基本層」として静的（変更されていない）のままです。これらのファイル（/ etc / hostsなど）のいずれかを編集して保存すると、ファイルシステムは元のファイルを変更せずにRAMディスクの最上位の「作業階層」に新しいコピーを作成します。これにより、ファイルシステムは元の代わりにこのコピーをユーザーに提供します。
RAMディスクのコピーは、バックグラウンドで、永続ストレージの3番目のレイヤーにも定期的に（rootユーザー設定可能）フラッシュされます。変更すると、RAMディスクのコピーは保存されたバージョンを効果的に上書きし、結果として静的ソースを上書きします。最上位コピーのみが表示されるため（変更されていないファイルの場合は元のファイルになります）、ファイルシステムはユーザーや他のソフトウェアに完全に一般的に見えます。
この技術はシステムの速度と安定性を向上させます。
- ユーザー起動ファイルの読み取りと書き込みは常にRAMディスクを使用するため、非常に高速です。
- RAMディスク層には最近変更されたファイルのみが含まれているため、サイズが小さく他の層と同様に機能します。隠れ家。
- 遅い永続的なリポジトリへのフラッシュは、バックグラウンド処理に延期されます。
- 「ファイルの保存」の3番目の階層のコピーは定期的に作成でき、設定またはインストールエラーが発生した場合、または悪意のあるプログラムが検出された場合は「元に戻す」機能を提供します。
シンボリックリンクがこれを可能にします。
答え...
どのように設定が「高速」ですか？
より多くのメモリを提供するほど、仮想ディスクに多くのプログラムを保存できるため、応答が速くなります。 RAMディスクからプログラムを起動するのは、フラッシュメモリ（フラッシュドライブ、SDなど）からプログラムを起動するよりも少し速く、ハードドライブから同じプログラムを起動するのにかかる時間の一部だけです。
64MB RAMを搭載した300MHz 1999 Toshiba 4030CDTノートブックでは、主にSlackwareをベースにしたPuppy Linux 5.2.2 Waryは、多くのRAMディスクのためのスペースが不足しているため、プログラムはハードドライブからロードされます。それにもかかわらず、2D-GUIは反応が非常に良いです。 Synergyを介して他のすべてのホストに接続するための「コンソール」として使用します。
一方、私は現在、ラップトップを介して2.6GHz Celeronプロセッサと1.3GB RAMを実行しているCompaq S6010Vを使用しています。ラムディスク「PuppySpace」には512MBが割り当てられており、そのうち現在200MB未満が使用されています。 Zim（Pythonメモ作成アプリケーション）、Geanyエディタ/IDE、5つのセッションが開いているターミナルクライアント、Chromiumの2つのコピーがロードされ、Gmailを含む合計12のアクティブなWebタブがあります。
通常どれくらいの期間オンになっていますか？
継続的に構成を開発して変更しているため、スケジュールされた再起動が一般的です。 Compaqの稼働時間出力は現在...
16:21:10 up 4 days, 7:28, load average: 0.06, 0.24, 0.30
ユーザーはkernel.orgで自分のカーネルを簡単にコンパイルして起動できますか？
これはやったことがないのでわかりませんね。 Puppy Linuxコミュニティは、朝食で自分のカーネルをコンパイルする人でいっぱいです。
これがサーバーを実行するのですか？
私のすべてのシステムはJWMまたはOpenboxウィンドウマネージャ（GTK +ベース）を実行していますが、Puppyをサーバーとして設定することをいくつかしました。レンプそして簡略化されたミュージックサーバージュークボックス（mpdPup）。
オルフス？ …その用途は何ですか？ （xfs/ext経由。
AufsはUnionfsを完全に書き直したものです。彼らはすべてそれを達成しました共同設置複数のファイルシステム（xfs、ext3/4など）が同じマウントポイントにマウントされ、互いに上書きされる場合。
答え3
今は/usr別のパーティションを作成しないことをお勧めします。これにより、シンボリックリンクはまったく必要ありません。
少なくともそれは私のディストリビューションでバイナリの移動に問題が発生した後に決定したものです。すべてのバイナリとライブラリを同じパーティションに配置することは本当に意味があります。そうすればどちらが/binあるのか、どれがあるのかは重要ではなく、/usr/bin勝手に移動できます。
/usr最初に別々のパーティションを作成した唯一の理由は、LVMを使用してすべてのパーティションを作成したからです。しかし、他には特別な理由はありません。別れのための別れ。
すべてのパーティションに1つのパーティションがある場合、ルート/パーティションはほぼ完全に空です。私の場合は200MB未満でした。そのため、これを/usrパーティションとマージして、以前にルートパーティションで無駄に無駄になったスペースを確保しました。まだ、欠点が見つかりませんでした。
構造システムのためのマージプロセス：（使用による責任はあなたにあります。システムが損傷する可能性があります。）
mkdir /mnt/root /mnt/usr
mount /dev/lvm/root /mnt/root
mount /dev/lvm/usr /mnt/usr
# /usr will be mounted as /, so move everything into a new usr/ subdirectory
mkdir /mnt/usr/usr
mv /mnt/usr/* /mnt/usr/usr/
# copy the root files, preserving hard links just in case
rsync -aH /mnt/root/. /mnt/usr/.
# update fstab: comment /usr, change UUID of / to the one of /usr
nano /mnt/usr/etc/fstab
umount /mnt/root
umount /mnt/usr
lvrename lvm/root lvm/oldroot
lvrename lvm/usr lvm/root
# chroot to see if it works and update grub UUID
mount /dev/lvm/root /mnt/root
mount -o bind /dev /mnt/root/dev
mount -o bind /proc /mnt/root/proc
mount -o bind /sys /mnt/root/sys
chroot /mnt/root /bin/bash
update-grub # may depend on distro/bootloader