web-dev-qa-db-ja.com

スライスCまたはスライス2がディスク全体をカバーするのはなぜですか

数人の友人と話し合っていたのですが、理解できませんでした。 FreeBSDおよびOpenSolaris/Solarisでは、ドライブをパーティション分割すると、ディスク全体をカバーするパーティションが作成されます。

da0s1c
c0d0s2

たとえば、OpenSolarisサーバーのメインハードドライブの出力は次のとおりです。

[email protected]:/dev/rdsk# prtvtoc /dev/rdsk/c4d0s2
* /dev/rdsk/c4d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*      63 sectors/track
*     255 tracks/cylinder
*   16065 sectors/cylinder
*    7296 cylinders
*    7294 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector 
*           0     16065     16064
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      2    00      16065 117145980 117162044
       2      5    01          0 117178110 117178109
       8      1    01          0     16065     16064

パーティション2を使用する理由は何でしたか？なぜパーティション0ではないのですか？ UNIXの歴史のどこでこれが決定されましたか？その時点でどのようなレガシー機能が提供されましたか？ （私が見つけたものから）完全になくなるGPTパーティショニングを使用します。

何か面白いもの...

ParoX GPTスタイルのパーティショニングとSolarisがvtocレイアウトの観点からそれをどのように表すかについて言及したので、これが1 TBであり、 ZFSアレイであり、GPTで自動的にセットアップされています。

[email protected]:~# prtvtoc /dev/rdsk/c5d0
* /dev/rdsk/c5d0 partition map
*
* Dimensions:
*     512 bytes/sector
* 1953520128 sectors
* 1953520061 accessible sectors
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector 
*          34       222       255
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       0      4    00        256 1953503455 1953503710
       8     11    00  1953503711     16384 1953520094
freebsdsolarispartition
14
X-Istence

昔は、ディスク全体の「dd」を使用してバックアップを行っていました。したがって、1つのコマンドですべてを実行できるように、「c」スライスを用意しました。

そのため、「c」スライスが存在します。

DDは完璧ではありません。ディスクが10％しかいっぱいでない場合、「ジャンク」または（たとえば）「スワップ」に使用される（バックアップには役に立たない）ブロックのコピーに90％の時間を費やします。 「dd」は、ディスクがほぼいっぱいにならない限り、または何らかの理由で正確なブロックごとのコピーが必要な場合を除いて、時間の無駄です。

これはすべて、RAID-0ディスクミラーリングとボリュームマネージャーがそのような種類のパーティションコピーをすべて行う前のことでした。

（誰かが「c」スライスで「ダンプ」について言及しました。それは機能しません。「ダンプ」はファイルごとのコピー[実際には、inodeごと]なので、機能しません。）

他の誰かが「なぜそれが最初のパーティションでも最後のパーティションでもないcなのか」と尋ねました。答えは「伝統」です。ケンかデニス（あるいはビル・ジョイかカーク・マックシック）が当時正当な理由を持っていたと私は推測することができるだけです。実際のパーティションには最初の2つのパーティションラベルを使用したと思います。それからある日、誰かがバックアップを実行するために重複するパーティションのアイデアを思いつき、「c」が次に利用可能なパーティションでした。当時は2〜3台のUnixマシンしかなかったので、これを2回実行すると、残りの時間に使用される「標準を設定」できます。

歴史的な事故が決してうまくいかない標準になる方法の別の例は、この記事で説明されています： bin、sbin、usr/bin、usr/sbinsplitを理解する

7
TomOnTime

これは、従来、スライスが次のように配置されていた結果です。

s0：ルート
s1：スワップ
s2：bkup

彼らは最初のスライスに最も重要なものを割り当て、重要性を下げ続けました：）（ルートパーティションがない場合、誰がスワップを必要としますか？さらに、データがない場合、誰が何かをバックアップする必要があります。）

これがいつ正確に決定されたかはわかりません（おそらくかなり早い段階で、Solaris開発者がSolarisスタイルのディスク識別子とスライスを使用することを決定したときはいつでも）。

MBRスタイルのパーティションスキームは適用できないため、この問題はGPTで解消されます。 （私はSolarisがGPTパーティションをどのように表すかについて個人的にはよく知りませんが...）

これがXDに役立つことを願っています


================
編集：
 今、あなたは私に興味を持っています。仕事に行く直前に見つけたリンクをいくつか投稿します。

Solaris 2.4 Sysadmin回答書：通常のスライス
Solaris 2.4ユーザーガイド：周辺機器の管理

これらのドキュメントはどちらも1994年頃のものであり、s2の作成を「フォーマット」に統合されたものとして定義しています。 XDを掘り続けなければならない！

4
ParoX

この質問の詳細：

http://en.wikipedia.org/wiki/BSD_disklabel によると、FreeBSDでは、他のオペレーティングシステムでも使用されているディスク上のcパーティションは、FreeBSDスライス全体にのみ拡張され、パーティションが作成されます。 dはハードドライブ全体になります！

Cパーティションは、専用モードではディスク全体、またはスライスモードではFreeBSDスライス全体をアドレス指定します。その他のパーティションは一般用です。

FreeBSD手動ディスク追加 18.3.1番号3を参照してください。

1
X-Istence

ヴィンテージのSunOSでscsiid 3がデフォルトのブートディスクだったのはなぜですか？

雨の中の涙のように、それらすべての瞬間は時間とともに失われます。

0
Ronald Pottol