Warum deckt Slice C oder Slice 2 die gesamte Festplatte ab?


14

Etwas, das ich mit ein paar Freunden besprochen habe und das wir nicht herausfinden konnten. In FreeBSD und OpenSolaris / Solaris wird beim Partitionieren eines Laufwerks eine Partition erstellt, die die gesamte Festplatte abdeckt:

da0s1c
c0d0s2

Zum Beispiel die Ausgabe meiner Hauptfestplatte auf meinem OpenSolaris-Server:

xistence@Keyhole.network.lan:/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

Was war der Grund für die Verwendung von Partition 2? Warum nicht Partition 0? Wo in der Geschichte von Unix wurde das entschieden? Welches Legacy-Feature war es zu diesem Zeitpunkt? Mit GPT-Partitionierung geht das ganz weg (von dem, was ich gefunden habe).

Nur etwas interessantes ...

Da ParoX die GPT-Partitionierung erwähnte und wie Solaris dies im Hinblick auf das vtoc-Layout darstellt, ist hier die Ausgabe von einer meiner Festplatten, die 1 TB groß ist und sich in einem ZFS-Array befindet und automatisch mit GPT eingerichtet wurde:

xistence@Keyhole.network.lan:~# 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

Ich habe nie wirklich so viel darüber nachgedacht, aber es ist faszinierend, dass du mich jetzt dazu gebracht hast, darüber nachzudenken. Neugierig, ob jemand antwortet.
Milner

Hmmm. Ich weiß, dass es in Solaris als "Backup" -Slice bezeichnet wurde. Ich frage mich, ob es eine Möglichkeit war, die gesamte Festplatte, einschließlich der Partitionszuordnung, in einem einzigen Speicherauszug zu sichern. Speichern Sie beispielsweise / dev / rdsk / c0t0d0s2 in einer Banddatei, und Sie können das gesamte physische Laufwerk, einschließlich des FS-Layouts, in einer Wiederherstellung wiederherstellen. Nur eine Vermutung. Konnte nichts mehr in Google finden. Gute Frage!
jj33

@ jj33: Klar, warum Slice 2 kaufen ? Warum nicht 0 oder -1 oder ein anderer markanter Wert?
Eddie

Antworten:


7

Früher haben wir Backups mit "dd" der gesamten Festplatte erstellt. Daher hatten wir das "c" -Slice, damit wir alles mit einem Befehl ausführen können.

Deshalb gibt es das "c" -Slice.

DD ist nicht perfekt. Wenn eine Festplatte nur zu 10% voll ist, verbringen Sie 90% Ihrer Zeit damit, Blöcke zu kopieren, die "Junk" sind oder (zum Beispiel) für "Swap" verwendet werden (nutzlos, um gesichert zu werden). "dd" ist Zeitverschwendung, es sei denn, Ihre Festplatte ist fast voll oder Sie benötigen aus irgendeinem Grund eine genaue blockweise Kopie.

Dies war alles, bevor RAID-0-Plattenspiegelung und Volume-Manager diese Art von Partitionskopien für Sie ausführten.

(Jemand erwähnte "dump" auf dem "c" -Slice. Das wird nicht funktionieren. "Dump" ist eine Datei-für-Datei-Kopie [tatsächlich Inode für Inode], sodass dies nicht funktioniert.)

Jemand anderes fragte "warum ist es c, nicht die erste Partition oder die letzte". Die Antwort lautet "Tradition". Ich kann nur vermuten, dass Ken oder Dennis (oder möglicherweise Bill Joy oder Kirk McKusick) zu dieser Zeit einen guten Grund hatten. Ich gehe davon aus, dass sie die ersten beiden Partitionsbezeichnungen für die tatsächlichen Partitionen verwendet hatten. Dann kam eines Tages jemand auf die Idee, eine überlappende Partition für Backups zu erstellen, und "c" war die nächste verfügbare Partition. Da es zu diesem Zeitpunkt nur 2-3 Unix-Maschinen gab, kann dies zweimal "den Standard setzen", der für den Rest der Zeit verwendet wird.

Ein weiteres Beispiel dafür, wie historische Unfälle zu Standards werden, die niemals funktionieren, finden Sie in diesem Artikel: Grundlegendes zu bin, sbin, usr / bin, usr / sbin split


Ja, aber warum c und nicht a ?
Cristian Ciupitu

1
Warum wurde dieser Brief gewählt? Ich weiß es nicht. Entweder Ritchie, Thompson oder vielleicht Bill Joy könnte das beantworten. Ich vermute, dass sie 0, dann 1 verwendet haben, und dann hat jemand diese geniale Idee einer überlappenden Partitionsbezeichnung. Der nächste Slot war verfügbar und viel sicherer als das Verschieben von Partitionen. Denken Sie daran ... dies war, als ganze Universitäten 1 oder 2 Computer hatten. Sie haben selten größere Systemänderungen vorgenommen. Es war nicht wie heute, wo Sie sich Ihre Maschinen frei vorstellen würden, wenn Sie eine solche Änderung vornehmen würden. Bei 50 Teilnehmern an einem Computer warten die Upgrades, bis alle bereit sind.
TomOnTime

4

Es ist ein Ergebnis der traditionellen Anordnung der Scheiben wie folgt:

s0: root
s1: swap
s2: bkup

Sie wiesen dem ersten Slice das Wichtigste zu und machten mit abnehmender Wichtigkeit weiter.

Ich weiß nicht, wann genau dies beschlossen wurde (wahrscheinlich ziemlich früh; wann immer sich die Solaris-Entwickler für die Verwendung von Festplattenkennungen und Slices im Solaris-Stil entschieden haben).

Das Problem verschwindet mit GPT, da das MBR-Partitionsschema nicht anwendbar ist. (Obwohl mir persönlich nicht bekannt ist, wie Solaris GPT-Partitionen darstellt ...)

Hoffe das hat geholfen XD


==============
Edit:
Jetzt hast du mich interessiert. Ich werde ein paar Links posten, die ich gefunden habe, bevor ich zur Arbeit gehe.

Solaris 2.4 Sysadmin-Antwortbuch: Standard-Slices
Solaris 2.4-Benutzerhandbuch: Peripheral Administration

Beide Dokumente stammen aus dem Jahr 1994 und definieren die Erstellung von s2 schon damals als in das 'Format' integriert. Muss weiter graben XD!


Es hilft, ist aber immer noch nicht die konkrete Antwort, die ich gesucht habe :-) Ich kannte bereits mögliche Gründe, warum und das Standard-Slice-Layout. Ich hätte gerne solide Beweise oder Beweise!
X-Istence

Gerne schleppe ich jemand anderen in den Wahnsinn dieser Frage :-).
X-Istence

Ok ... Das Konzept der Slices scheint irgendwo um die Releases von BSD 4.2 und Unix System V.4 (1984-1989) entstanden zu sein ... Zeit, die Bibliothek aufzusuchen>. <(Es gab nicht viel Internet-Protokollierung zu diesem Zeitpunkt aus offensichtlichen Gründen.)
ParoX

docsrv.sco.com/cgi-bin/man/man?vtoc+7 Anscheinend verwendet UnixWare s0 als die gesamte Partition mit s1 und s2 als Root bzw. Swap. Interessant ...
ParoX

1
Ich beschränke dies auf die Einführung von UFS im Jahr 1982 im BSD-Baum. Ich bin jetzt ziemlich zuversichtlich, dass SVR das Konzept in der
Version

1

Weitere Informationen zu dieser Frage:

Laut http://en.wikipedia.org/wiki/BSD_disklabel unter FreeBSD erstreckt sich die c-Partition auf einer Festplatte, die auch von anderen Betriebssystemen verwendet wird, nur auf das gesamte FreeBSD-Slice, und Partition d ist die gesamte Festplatte !

Die c-Partition adressiert die gesamte Festplatte im dedizierten Modus oder den gesamten FreeBSD-Slice im Slice-Modus. Die anderen Partitionen sind für den allgemeinen Gebrauch.

FreeBSD Manual Disk Adding siehe 18.3.1 Nummer 3.


0

Warum war scsi id 3 Ihre Standard-Bootdiskette in Sun OS?

All diese Momente werden in der Zeit verloren gehen, wie Tränen im Regen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.