web-dev-qa-db-ja.com

Linuxはどのアルゴリズムに従ってハードドライブ文字を割り当てますか？

同じシステムを繰り返し起動すると、デバイス名間のマッピングが/dev/sda、/dev/sdb/...と物理ハードドライブは同じままです。

ただし、ハードドライブをマザーボードの別のソケットに接続した場合や、ドライブを追加または削除した場合でも、同じままかどうかはわかりません。

Linuxは、物理ハードドライブへのデバイス名のマッピングに関してどのような保証をしますか？

物理ハードドライブを/ dev /内のファイルにマップするためにどのルールを使用しますか？

mountdevicesautomounting
4
Konstantin Schubert

ラベルでマウントする外部USBドライブがあるため、fstabの実行時に常にマウントされますが、それでも問題が解決しません。デバイスがマウントされていてもドライブの割り当てが変更され、変更されたドライブ上のファイルにアクセスできなくなる場合があります。

Ubuntu 16.04.4 LTS（Linux 4.4.0-128-generic i686）を実行しています。

私は毎日のセッションの間にスリープモードを使用しており、スリープモードから復帰したときにドライブが再割り当てされると思いますが、これについては完全にはわかりません。通常は/ dev/sdcが割り当てられており、プラグインしたままのUSB SDカードリーダーがあり、/ dev/sddが割り当てられています。外付けドライブから読み書きできない場合があります。これが発生すると、/ dev/sdeに再割り当てされたことがわかります。 1つの修正は単にOSを再起動することです、そしてすべてが満足のいく状態に戻りますが、私はその極端に行く必要がない修正を探しています。

より良い修正方法は、外部ドライブのパーティション上のフォルダーにあるターミナルタブを含め、外部ドライブのパーティションにアクセスしているアプリケーションを最初に閉じることです。アクセスできないドライブ上のファイルに変更を加えたアプリケーションを使用している場合、1）データが保存されるように、2）データを破壊するために、ファイルを別のアクセス可能なパーティションに保存する必要があります。アクセスできないパーティションへのリンク。次に、パーティションをアンマウントします

Sudo umount /dev/sde

または外付けドライブのすべてのパーティションの割り当て。次に、すべてのパーティションを再マウントします

Sudo mount -a

これを実行すると、予期された/ dev/sdcの代わりに/ dev/sdeが割り当てられている場合でも、誤ったパーティションにアプリケーションから再びアクセスできるようになりました。 fstabはラベルを操作し、これらのパーティションをフォルダーにマウントするため、この再割り当ては問題になりません。私はこれを月に2、3回行わなければならないようです。

パーティションの識別にラベルを使用していても、mountがラベルをデバイスの文字割り当てにマップしている場合、この問題の原因となっているのではないかと思います。確かに言えない...ただ考えているだけだ。

0
Randyman99

関連する質問（自動サイドバーから）： ブート間の/ sda/sdbの変更を防ぐ方法？

カーネルによって「プローブ」（または「バインド」）された順序でそれらを割り当てることが保証されます。

Greg KHはこの命令に依存しないことを提唱しています。彼は、（実際に！）恐ろしく設計されたマザーボードの例を挙げて、後続のブート間でPCI順序を再配置するのが好きです。上記の質問はそのような例の1つについてのようです。

ロード可能なモジュールはユーザースペースによってロードされます。 udevは複数のプロセスを使用して並列化され、特定の順序でモジュールをロードすることを保証しません。このように初期化を並列化すると、モジュールの初期化関数が並列に実行される可能性があり、これらの関数にハードウェアを待機する長い遅延が含まれる可能性があるため、パフォーマンスが大幅に向上します。

現在、カーネルdefaultはbuilt-inドライバーを同期的に、したがって確定的な順序でプローブすることを前提とすることができます。 。

V4.2以降、Linuxカーネルは非同期プローブサポートをスポーツします

（どうやらこの機能はGoogleで使用されているChrome OS）。

https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

https://kernelnewbies.org/Linux_4.2#Core

歴史的メッセージ に基づいて、特にLinusから、そのような取り組みについて懐疑的/疲労があると仮定した可能性もあります。上記に基づいて、どのような強化された精査および/または荒れ狂う大げさなメッセージも、このオプションをマージすることの邪魔にならなかったようです。

「[一部の]ドライバーは、ドライバーのバグや最適なドライバー構成ではないため、非同期プローブではうまく機能しない」ため、カーネル全体で有効にすることも別の問題です。たぶん、Linusは「最終的な目的はデフォルトでプローブを非同期にすることです」と言っているマージされたコミットメッセージで爆発しなかった（？） v4.2。

0
sourcejedi

Linuxは、物理ハードドライブへのデバイス名のマッピングに関してどのような保証をしますか？

物理ハードドライブを/ dev /内のファイルにマップするためにどのルールを使用しますか？

すべてのLinuxディストリビューションについて話すことはできませんが、SUSEがどのように行うかについて話すことができます。SUSEでは、これらのオプションが利用可能です

マウント/

  • 装置名
  • デバイスID
  • ボリュームラベル
  • デバイスパス
  • UUID

byデバイス名badとすると、Linuxがチェックするためハードウェアおよび order でドライブが接続されていると見なされるのは、sdaやsdbなどへのマッピングの方法です。したがって、ブートデバイスとパーティションがsdaとして呼び出され、リムーバブルスロット（サーバー上）のドライブの順序を切り替えるか、2台のドライブ間のホームコンピューターのSATAケーブルを切り替えると、問題が発生します。また、私の経験では（8、16、または24ドライブベイのサーバーで）、ドライブスロット0がsdaにマップされないことがしばしば後退しています... 3つのドライブがある場合、スロット2はsda、スロット1はsdb、スロット0 sdc。そして、_/dev/sda_としてマップされ、ドライブを押し下げて物事を混乱させる一時的なハードウェアを追加します。ただし、クローンを作成するゴールドイメージのオペレーティングシステムドライブを設定する場合は、この方法が適していると言えます...少しの間、新しいドライブでハードドライブIDやWWNが変更されることを心配する必要はありません。 ..システム内のonlyディスクの場合、常にsdaとして表示される可能性があります。

_FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0
_

by device id は、basically「デバイス名による」で言及したすべての問題を解決するため、常に使用します。何年にもわたって私には何年にもわたってうまく機能してきました。マウントがデバイスIDによって構成されたら、ドライブが存在するか接続されている必要があります。ドライブが移動したり、新しいハードウェアが一部の_/dev/sd?_としてマップされたりしても、以前に構成されたものには影響しません。

_FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0
_

by UUID {universally unique identifier} 私も良い方法だと思います。「by device-id」とよく似ていますが、UUIDがどのように作成されて一意にされるのかわかりませんが、または、それがデバイスIDと同じになる場合はどうなりますか？

by volume label は、マウントするファイルシステム、パーティション、またはボリュームにあなたまたは誰かが適切なボリュームラベルを付けていれば、うまく機能します。 2つのパーティションに同じボリュームラベルが付いている場合、たとえば「ブート」のように問題があると私は確信していますIsuspectlablel linuxが最初に検出したボリュームのいずれかが重複するボリュームラベルを報告しない場合に使用します。

また、これはすべてLinux Udevに基づいています（使用するアルゴリズムの一種の回答）。 UdevはほとんどすべてのLinuxディストリビューションで使用されているパッケージであるため、古いInit Linuxでも新しいSystemd Linuxでも同じだと思います。そして、I thinkほとんどが_/etc/fstab_の構文です特に、各行の最初のフィールドまたは列は何ですか発生するマウント方法を決定します（アルゴリズムではありません）。どこかに他の構成ファイルがないため、_/etc/fstab_に複数の行があり、それぞれが異なるマウント方法（名前で、 id、uuid、またはlabel）、そしてfstabファイルの構文を除いて、他に何も変更されていないことがわかっています。

0
ron