Почему срез C или срез 2 охватывает весь диск

Что-то, что я обсуждал с парой друзей, и мы не смогли понять это. В FreeBSD и OpenSolaris / Solaris при разбиении диска создается раздел, охватывающий весь диск:

da0s1c
c0d0s2

Например, вывод моего основного жесткого диска на мой сервер 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

Что послужило причиной использования раздела 2? Почему не раздел 0? Где в истории Unix это было решено? Какой унаследованной функции он служил на тот момент? С разделением GPT это полностью исчезает (из того, что я нашел).

Просто что-то интересное ...

Так как ParoX упомянул разделение в стиле GPT и то, как Solaris представляет это с точки зрения разметки vtoc, вот вывод с одного из моих дисков объемом 1 ТБ, который находится в массиве ZFS и автоматически настроен с помощью 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

В старые времена мы делали резервные копии, используя «dd» всего диска. Поэтому у нас был срез «c», чтобы мы могли делать все это одной командой.

Вот почему срез "c" существует.

ДД не идеален. Если диск заполнен только на 10%, вы тратите 90% своего времени на копирование блоков, которые являются «мусорными» или (например) используются для «подкачки» (бесполезно для резервного копирования). «dd» - пустая трата времени, если ваш диск почти не заполнен или по какой-то причине вам нужна точная, блочная копия.

Это было все до того, как зеркалирование дисков RAID-0 и менеджеры томов сделали за вас такое копирование разделов.

(Кто-то упомянул «dump» в срезе «c». Это не сработает. «Dump» - это копия файла за файлом [фактически, inode by inode], поэтому она не будет работать.)

Кто-то еще спросил «почему это c, а не первый раздел или последний». Ответ - «традиция». Я могу только догадываться, что у Кена или Денниса (или, возможно, Билла Джоя или Кирка МакКусика) в то время были веские причины. Я предполагаю, что они использовали первые две метки раздела для реальных разделов. Затем однажды у кого-то возникла идея перекрывающегося раздела для создания резервных копий, и «c» был следующим доступным разделом. Поскольку в то время было всего 2-3 Unix-машины, выполнение этого дважды может «установить стандарт», который используется в остальное время.

В этой статье описывается еще один пример того, как исторические аварии становятся стандартами, которые никогда не выходят за рамки: Понимание bin, sbin, usr / bin, usr / sbin split

Это результат того, что ломтики традиционно раскладываются следующим образом:

s0: корень
s1: своп
s2: bkup

Они назначили самую важную вещь первому срезу и продолжили с уменьшением важности :) (Кому нужен своп, если у вас нет корневого раздела? Далее, кому нужно что-то делать, если у вас нет данных.)

Я не знаю, когда именно это было решено (вероятно, довольно рано; всякий раз, когда разработчики Solaris решили использовать идентификаторы дисков и срезы в стиле Solaris).

Проблема исчезает с GPT, поскольку схема разделов в стиле MBR не применима. (Хотя я лично не знаком с тем, как Solaris представляет разделы GPT ...)

Надеюсь, что это помогло XD


================
Редактировать:
Теперь вы заинтересовали меня. Я опубликую несколько ссылок, которые я нашла перед тем, как отправиться на работу.

Книга ответов Solaris 2.4 Sysadmin: обычные срезы
Руководство пользователя Solaris 2.4: периферийное администрирование

Оба эти документа относятся к 1994 году, и они определяют создание s2 как интегрированное в «формат» уже тогда. Должен продолжать копать XD!

Подробнее об этом вопросе:

Согласно http://en.wikipedia.org/wiki/BSD_disklabel во FreeBSD, раздел c на диске, который также используется другими операционными системами, будет распространяться только на весь фрагмент FreeBSD, а раздел d будет представлять собой весь жесткий диск. !

Раздел c обращается ко всему диску в выделенном режиме или ко всему слайсу FreeBSD в режиме слайса. Другие разделы предназначены для общего пользования.

Добавление FreeBSD на диск, см. 18.3.1, номер 3.

Почему scsi id 3 был вашим загрузочным диском по умолчанию в винтажной ОС Sun?

Все эти моменты будут потеряны во времени, как слезы под дождем.