Dlaczego plasterek C lub 2 obejmuje cały dysk

Coś, o czym rozmawiałem z kilkoma przyjaciółmi i nie byliśmy w stanie tego rozgryźć. W FreeBSD i OpenSolaris / Solaris podczas partycjonowania dysku tworzona jest partycja obejmująca cały dysk:

da0s1c
c0d0s2

Na przykład dane wyjściowe z mojego głównego dysku twardego na moim serwerze 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

Jakie było uzasadnienie zastosowania partycji 2? Dlaczego nie partycji 0? Gdzie w historii Unixa tak się zdecydowało? Jaką starszą funkcję służyła w tym momencie? Z partycjonowaniem GPT, które całkowicie odchodzi (od tego, co znalazłem).

Po prostu coś interesującego ...

Ponieważ ParoX wspomniał o partycjonowaniu w stylu GPT i tym, jak Solaris reprezentuje to pod względem układu vtoc, oto dane wyjściowe z jednego z moich dysków, który ma 1 TB i jest w tablicy ZFS i został automatycznie skonfigurowany z 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

W dawnych czasach robiliśmy kopie zapasowe przy użyciu „dd” całego dysku. Dlatego mieliśmy wycinek „c”, abyśmy mogli zrobić to wszystko za pomocą jednego polecenia.

Właśnie dlatego istnieje wycinek „c”.

DD nie jest idealny. Jeśli dysk jest zapełniony tylko w 10%, spędzasz 90% czasu na kopiowaniu bloków, które są „śmieciowe” lub (na przykład) są używane do „zamiany” (bezużyteczne do utworzenia kopii zapasowej). „dd” to strata czasu, chyba że dysk jest prawie pełny lub jeśli z jakiegoś powodu potrzebujesz dokładnej, blok po kopii, kopii.

Stało się to przed tym, jak dublowanie dysków RAID-0 i menedżery woluminów wykonali dla Ciebie tego rodzaju kopiowanie partycji.

(Ktoś wspomniał o „zrzutu” na wycinku „c”. To nie zadziała. „Zrzut” to kopia plik po pliku [właściwie, i-węzeł przez i-węzeł], więc to nie zadziała.)

Ktoś inny zapytał „dlaczego to jest c, a nie pierwsza partycja lub ostatnia”. Odpowiedź brzmi „tradycja”. Mogę tylko zgadywać, że Ken lub Dennis (lub ewentualnie Bill Joy lub Kirk McKusick) mieli wtedy dobry powód. Zakładam, że użyli pierwszych dwóch etykiet partycji dla rzeczywistych partycji. Pewnego dnia ktoś wpadł na pomysł, aby partycja nakładała się na kopie zapasowe, a „c” była następną dostępną partycją. Ponieważ w tym czasie istniały tylko 2-3 maszyny uniksowe, zrobienie tego dwa razy może „ustawić standard”, który będzie używany przez resztę czasu.

Kolejny przykład tego, jak wypadki historyczne stają się standardami, które nigdy się nie zmieniają, opisano w tym artykule: Zrozumienie podziału bin, sbin, usr / bin, usr / sbin

Wynika to z tradycyjnego ułożenia plasterków w następujący sposób:

s0: root
s1: zamiana
s2: bkup

Przydzielili najważniejszą rzecz do pierwszego wycinka i kontynuowali z malejącym znaczeniem :) (Kto potrzebuje zamiany, jeśli nie masz partycji root? Ponadto, kto musi wykonać kopię zapasową, jeśli nie masz danych.)

Nie wiem, kiedy dokładnie podjęto taką decyzję (prawdopodobnie dość wcześnie; ilekroć deweloperzy Solaris decydowali się na użycie identyfikatorów dysków i plasterków w stylu Solaris).

Problem zniknął w przypadku GPT, ponieważ schemat partycji w stylu MBR nie ma zastosowania. (Chociaż osobiście nie jestem zaznajomiony z tym, jak Solaris reprezentuje partycje GPT ...)

Mam nadzieję, że to pomogło XD


================
Edycja:
Teraz mnie zainteresowałeś. Opublikuję kilka linków, które znalazłem tuż przed wyruszeniem do pracy.

Książka z odpowiedziami systemu Solaris 2.4 Sysadmin: Niestandardowe plastry
Podręcznik użytkownika Solaris 2.4: Administracja urządzeń peryferyjnych

Oba te dokumenty pochodzą z około 1994 roku i nawet wtedy definiują tworzenie s2 jako zintegrowane z „formatem”. Muszę dalej kopać XD!

Więcej informacji na temat tego pytania:

Według http://en.wikipedia.org/wiki/BSD_disklabel na FreeBSD partycja c na dysku, który jest również używany przez inne systemy operacyjne, rozciąga się tylko na cały wycinek FreeBSD, a partycja d byłaby całym dyskiem twardym !

Partycja c dotyczy całego dysku w trybie dedykowanym lub całego wycinka FreeBSD w trybie wycinania. Pozostałe partycje są do ogólnego użytku.

Ręczne dodawanie dysku FreeBSD patrz 18.3.1 numer 3.

Dlaczego scsi id 3 jest domyślnym dyskiem rozruchowym w klasycznym systemie operacyjnym Sun?

Wszystkie te chwile zostaną zatracone w czasie, jak łzy w deszczu.