Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
    
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 6 '09 at 0: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 6 '09 at 1:00
    
@jj33: Sure, buy why slice 2? Why not 0 or -1 or some other distinctive value? –  Eddie May 6 '09 at 2:01
add comment

4 Answers

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

share|improve this answer
    
Yes, but why c and not a? –  Cristian Ciupitu Sep 2 '09 at 2:50
1  
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
add comment

Why was scsi id 3 your default boot disk in vintage Sun OS?

All those moments will be lost in time, like tears in rain.

share|improve this answer
add comment

More information about this question:

According to http://en.wikipedia.org/wiki/BSD_disklabel on FreeBSD the c partition on a disk that is also in use by other operating systems will only extend onto the entire FreeBSD slice, and partition d would be the entire hard drive!

The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use.

FreeBSD Manual Disk Adding see 18.3.1 number 3.

share|improve this answer
add comment

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!

share|improve this answer
    
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 6 '09 at 7:39
    
Happy to drag someone else into the madness that is this question :-). –  X-Istence May 6 '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 6 '09 at 16:31
    
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 6 '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 7 '09 at 2:00
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.