Why does slice C or slice 2 cover the entire disk

Question

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:

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

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:

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

Never really thought about it that much, but it is intriguing now that you got me thinking about it. Curious to see if anyone answers. — Milner, May 06 '09 at 00:33
hmmm. I know in Solaris it was referred to as the "backup" slice. I wonder if it was a way to backup the entire disk, including partition map, in one dump? Like, dump /dev/rdsk/c0t0d0s2 to a tape file and your could recover the entire physical drive, including FS layout, in one restore? Just a guess. Couldn't find anything more in google. Good question! — jj33, May 06 '09 at 01:00
@jj33: Sure, buy why slice **2**? Why not 0 or -1 or some other distinctive value? — Eddie, May 06 '09 at 02:01

TomOnTime · Answer 1 · 2012-02-08T13:08:05.857

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

Why was that letter chosen? I don't know. Either Ritchie, Thompson, or maybe Bill Joy could answer that. My guess is that they used 0, then 1, then someone has this brilliant idea of an overlapping partition label. The next slot was available, and a lot safer than moving partitions around. Remember... this was when entire universities had 1 or 2 computers. You did major system changes rarely. It wasn't like today where if you were making a change like this you would freely re-imagine your machines. With 50 people all sharing one computer, upgrades wait until everyone is ready. — TomOnTime, Sep 25 '09 at 17:54

ParoX · Answer 2 · 2009-05-06T15:06:32.060

4

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!

edited May 06 '09 at 15:06

answered May 06 '09 at 03:35

ParoX

838
6
11

It helps, but is still not the concrete answer I was looking for :-) I already knew possible reasons as to why, and the default slice layout. I would like solid evidence or proof! – X-Istence May 06 '09 at 07:39
Happy to drag someone else into the madness that is this question :-). – X-Istence May 06 '09 at 15:35
Ok... The concept of slices seems to have originated somewhere around the releases of BSD 4.2 and Unix System V.4 (1984-1989)... Time to hit up the library >.< (There wasn't much internet logging at that time for obvious reasons.) – ParoX May 06 '09 at 16:31
http://docsrv.sco.com/cgi-bin/man/man?vtoc+7 Apparently UnixWare uses s0 as the entire partition with s1 and s2 as root and swap respectively. Interesting... – ParoX May 06 '09 at 20:10
1

I'm narrowing this down to the introduction of UFS in 1982 in the BSD tree. I'm now quite confident that SVR borrowed the concept from BSD in its 4.2 Release (after rummaging through a ton of old programmer's references.) I'll hit up the library again tomorrow lol – ParoX May 07 '09 at 02:00
Sounds like a question for Marshall McKusick, the fella behind so much of UFS and FFS... – Mei Jun 08 '09 at 18:43

score 1 · Answer 3 · answered May 06 '09 at 22:38

Why does slice C or slice 2 cover the entire disk

4 Answers4