Why does slice C or slice 2 cover the entire disk

Something that I was discussing with a couple of friends and we were unable to figure it out. In FreeBSD and OpenSolaris/Solaris when you partition a drive a partition is created that covers the whole disk:

da0s1c
c0d0s2

For example, the output of my main hard drive in my OpenSolaris server:

[email protected]:/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

What was the reasoning behind using partition 2? Why not partition 0? Where in the history of unix was this decided? What legacy feature did it serve at that point in time? With GPT partitioning that goes away entirely (from what I have found).

Just something interesting ...

Since ParoX mentioned GPT style partitioning and how Solaris represents that in terms of vtoc layout, here is the output from one of my disks that is 1 TB and is in a ZFS array, and has automatically been set up with GPT:

[email protected]:~# 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

Solution 1:

Back in the old days we would do backups using "dd" of the entire disk. Therefore, we had the "c" slice so that we could do it all with one command.

That's why the "c" slice exists.

DD isn't perfect. If a disk is only 10% full you spend 90% of your time copying blocks that are "junk" or (for example) are used for "swap" (useless to be backed up). "dd" is a waste of time unless your disk is nearly full or if, for some reason, you need an exact, block-by-block, copy.

This was all before RAID-0 disk mirroring and volume managers did all that kind of partition copying for you.

(Someone mentioned "dump" on the "c" slice. That won't work. "dump" is a file-by-file copy [actually, inode by inode] so that won't work.)

Someone else asked "why is it c, not the first partition, or the last". The answer is "tradition". I can only guess that Ken or Dennis (or possibly Bill Joy or Kirk McKusick) had a good reason at the time. I assume they had used the first two partition labels for actual partitions. Then one day someone had the idea of the over-lapping partition for doing backups and "c" was the next partition available. Since there were only 2-3 Unix machines at the time, doing this twice can "set the standard" that gets used for the rest of time.

Another example of how historic accidents become standards that never go way is described in this article: Understanding the bin, sbin, usr/bin , usr/sbin split

Solution 2:

It's a result of the slices traditionally being laid out as follows:

s0: root
s1: swap
s2: bkup

They assigned the most important thing to the first slice and continued with decreasing importance :) (Who needs swap if you have no root partition? Further, who needs to backup anything if you have no data.)

I don't know when exactly this was decided upon (probably fairly early on; whenever the Solaris devs decided to use Solaris-style disk identifiers and slices.)

The problem goes away with GPT since the MBR style partition scheme is not applicable. (Though I'm personally not familiar with how Solaris represents GPT partitions...)

Hope this helped XD


================
Edit:
Now you've got me interested. I'll post a few links I found just before I head off to work.

Solaris 2.4 Sysadmin answer book: Customary slices
Solaris 2.4 User Guide: Peripheral Administration

Both these docs are circa 1994 and they define the creation of s2 as integrated into 'format' even then. Gotta keep digging XD!