Perché la fetta C o la fetta 2 coprono l'intero disco

Qualcosa di cui stavo discutendo con un paio di amici e non siamo riusciti a capirlo. In FreeBSD e OpenSolaris / Solaris quando si partiziona un'unità viene creata una partizione che copre l'intero disco:

da0s1c
c0d0s2

Ad esempio, l'output del mio disco rigido principale nel mio server OpenSolaris:

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

Qual è stato il ragionamento alla base dell'utilizzo della partizione 2? Perché non partizionare 0? Dove nella storia di Unix è stato deciso? Quale funzione legacy ha servito in quel momento? Con il partizionamento GPT che scompare del tutto (da quello che ho trovato).

Solo qualcosa di interessante ...

Dato che ParoX ha menzionato il partizionamento in stile GPT e come Solaris lo rappresenta in termini di layout vtoc, ecco l'output di uno dei miei dischi che è 1 TB ed è in un array ZFS ed è stato automaticamente impostato con GPT:

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

Ai vecchi tempi avremmo fatto i backup usando "dd" dell'intero disco. Pertanto, abbiamo avuto la sezione "c" in modo da poter fare tutto con un solo comando.

Ecco perché esiste la sezione "c".

DD non è perfetto. Se un disco è pieno solo al 10%, si impiega il 90% del tempo a copiare blocchi "spazzatura" o (ad esempio) utilizzati per "scambio" (inutili per il backup). "dd" è una perdita di tempo a meno che il disco non sia quasi pieno o se, per qualche motivo, è necessaria una copia esatta, blocco per blocco.

Tutto questo prima che il mirroring del disco RAID-0 e i gestori dei volumi facessero tutto quel tipo di copia delle partizioni per te.

(Qualcuno ha citato "dump" sulla sezione "c". Non funzionerà. "Dump" è una copia file per file [in realtà, inode per inode] in modo che non funzioni.)

Qualcun altro ha chiesto "perché è c, non la prima partizione o l'ultima". La risposta è "tradizione". Posso solo supporre che Ken o Dennis (o forse Bill Joy o Kirk McKusick) abbiano avuto un buon motivo in quel momento. Presumo che abbiano usato le prime due etichette di partizione per le partizioni effettive. Quindi un giorno qualcuno ebbe l'idea della partizione sovrapposta per fare i backup e "c" era la successiva partizione disponibile. Dal momento che c'erano solo 2-3 macchine Unix al momento, farlo due volte può "stabilire lo standard" che viene utilizzato per il resto del tempo.

Un altro esempio di come gli incidenti storici diventano standard che non vanno mai di pari passo è descritto in questo articolo: Comprendere bin, sbin, usr / bin, usr / sbin split

È il risultato delle sezioni tradizionalmente disposte come segue:

s0: root
s1: swap
s2: bkup

Hanno assegnato la cosa più importante alla prima sezione e hanno continuato con importanza decrescente :) (Chi ha bisogno di scambiare se non si dispone di una partizione di root? Inoltre, chi ha bisogno di eseguire il backup di qualcosa se non si dispone di dati.)

Non so quando sia stato deciso esattamente questo (probabilmente abbastanza presto; ogni volta che gli sviluppatori di Solaris hanno deciso di utilizzare identificatori e slice di dischi in stile Solaris).

Il problema scompare con GPT poiché lo schema di partizione in stile MBR non è applicabile. (Anche se personalmente non ho familiarità con il modo in cui Solaris rappresenta le partizioni GPT ...)

Spero che questo abbia aiutato XD


================
Modifica:
ora mi hai interessato. Pubblicherò alcuni link che ho trovato poco prima di andare al lavoro.

Libro delle risposte su Sysadmin di Solaris 2.4: sezioni personalizzate
Guida dell'utente di Solaris 2.4: amministrazione periferica

Entrambi questi documenti risalgono al 1994 circa e definiscono la creazione di s2 come integrata nel "formato" anche allora. Devo continuare a scavare XD!

Maggiori informazioni su questa domanda:

Secondo http://en.wikipedia.org/wiki/BSD_disklabel su FreeBSD la partizione c su un disco che è anche in uso da altri sistemi operativi si estenderà solo sull'intera porzione di FreeBSD, e la partizione d sarebbe l'intero disco rigido !

La partizione c indirizza l'intero disco in modalità dedicata, o l'intera porzione di FreeBSD in modalità fetta. Le altre partizioni sono per uso generale.

Aggiunta manuale del disco di FreeBSD vedi 18.3.1 numero 3.

Perché scsi id 3 era il disco di avvio predefinito nel sistema operativo Sun vintage?

Tutti quei momenti andranno persi nel tempo, come lacrime nella pioggia.