Назад | Перейти на главную страницу

Почему срез 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».

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

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

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

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

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

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

s0: корень
s1: поменять местами
s2: bkup

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

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

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

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


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

Книга ответов системного администратора Solaris 2.4: Обычные срезы
Руководство пользователя 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?

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