슬라이스 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이 아닌가? 유닉스 역사상 어디에서 이것이 결정 되었습니까? 이 시점에서 어떤 레거시 기능이 제공 되었습니까? GPT 파티셔닝으로 완전히 사라졌습니다 (내가 찾은 것에서).

흥미로운 것 ...

이후 ParoX는 GPT 스타일의 파티션을 언급 및 Solaris VTOC 레이아웃의 관점에서 그 표현 방법, 여기에 1 TB는과 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"슬라이스에서 "덤프"를 언급했습니다. 작동하지 않습니다. "덤프"는 파일 별 사본 (실제로는 inode에 의한 inode)이므로 작동하지 않습니다.)

다른 사람이 "첫 번째 파티션이 아닌 c가 왜 c입니까?"라고 물었습니다. 답은 "전통"입니다. 나는 Ken이나 Dennis (또는 Bill Joy 또는 Kirk McKusick)가 당시에 합당한 이유가 있다고 추측 할 수 있습니다. 실제 파티션에 처음 두 개의 파티션 레이블을 사용했다고 가정합니다. 그러던 어느 날 누군가가 백업을 수행하기 위해 오버 랩핑 파티션에 대한 아이디어를 얻었고 다음 파티션은 "c"였습니다. 당시에는 2-3 대의 Unix 머신 만 있었기 때문에이 작업을 두 번 수행하면 남은 시간에 "표준"을 설정할 수 있습니다.

역사적 사고가 결코 진행되지 않는 표준이되는 방법의 또 다른 예는이 기사에서 설명 합니다. bin, sbin, usr / bin, usr / sbin split 이해

슬라이스가 전통적으로 다음과 같이 배치 된 결과입니다.

s0 : 루트
s1 : 스왑
s2 : bkup

그들은 첫 번째 슬라이스에 가장 중요한 것을 할당하고 중요성을 계속 줄였습니다.

나는 이것이 정확히 언제 결정되었는지 알지 못합니다 (아마도 초기에; Solaris 개발자가 Solaris 스타일 디스크 식별자와 슬라이스를 사용하기로 결정할 때마다).

MBR 스타일 파티션 구성표가 적용되지 않기 때문에 GPT에서 문제가 사라집니다. (개인적으로 솔라리스가 GPT 파티션을 나타내는 방식에 익숙하지는 않지만 ...)

이것이 XD에 도움이 되었기를 바랍니다


================
편집 :
이제 관심이 생겼습니다. 출근 직전에 찾은 몇 가지 링크를 게시하겠습니다.

Solaris 2.4 Sysadmin 답변서 : 사용자 정의 슬라이스
Solaris 2.4 사용 설명서 : 주변 장치 관리

이 두 문서는 모두 1994 년경이며 s2 작성을 '포맷'에 통합 된 것으로 정의합니다. XD를 계속 파고 야 해요!

이 질문에 대한 추가 정보 :

FreeBSD의 http://en.wikipedia.org/wiki/BSD_disklabel 에 따르면 다른 운영 체제에서도 사용중인 디스크의 c 파티션은 전체 FreeBSD 슬라이스까지만 확장되며 d는 전체 하드 드라이브가됩니다. !

c 파티션은 전용 모드에서 전체 디스크 또는 슬라이스 모드에서 전체 FreeBSD 슬라이스를 처리합니다. 다른 파티션은 일반적으로 사용됩니다.

FreeBSD 수동 디스크 추가 18.3.1 번호 3 참조.

빈티지 Sun OS에서 scsi id 3이 기본 부트 디스크 인 이유는 무엇입니까?

비가 내리는 눈물처럼 모든 순간은 시간이 지나면 사라집니다.