Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shodha.enet.dec.com!alan
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: Adding/setting up mem, disk, cd drive, sys admin?
Summary: Long reply, Part II.  Mathematics of Disk Geometry.
	 or "Lies, Damned Lies, and Real Track Lengths".
Message-ID: <3387@shodha.enet.dec.com>
Date: 16 Jun 91 05:11:28 GMT
References: <44675@netnews.upenn.edu>
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 66



In article <44675@netnews.upenn.edu>, lau@desci.wharton.upenn.edu (Yan K. Lau) writes:
> I added 2 RZ57s in an expansion unit to the system.  I ran MAKEDEV and
> newfs.  The results were about 950megs total with 850megs available.  Is
> this normal?  I read somewhere that the system takes about 10% for
> (mumble...mumble).  

	And I responded "This seems to be normal".  Well, upon
	closer examination there's something funny about the RZ57
	and perhaps all the DEC SCSI disks.  Perhaps it's just an
	editing error on the part of whoever maintains /etc/disktab,
	but it none the less curious.

	From /etc/disktab we can discover that the size of the C
	partition of an RZ57 is 2,025,788 sectors or 989.15 MB.  
	However if we look at the output of chpt -q we see that 
	ULTRIX really believes there are only 1,954,050 sectors 
	(954.13 MB).  If we look at the geometry information in 
	disktab then we get yet a third number.  We are led to 
	believe the RZ57 has 71 sectors per track, 15 tracks per 
	cylinder and 1,925 cylinders.  This give us 2,050,125 sectors 
	or (1,001.04 MB).

	Now it might be that the 71 sectors per track includes a sector 
	or two used for bad block replacement.  Setting aside a sector
	on each track for a replacement block can make BBR go faster
	if you can get the LBN of the replacement block from the sector
	header.  So this may mean that there are really on 70 or perhaps
	69 sectors per track.  It's also possible a couple of cylinders
	have been set aside for diagnostic use.  Or it might be that
	we lie about the geometry in /etc/disktab for some reason.

	Ah, let try a different tact.  How do the three different
	numbers factor into interesting values (*)?

	   Disktab:  2025788 = 2 * 2 * 17 * 31 * 31 * 31
	   Chpt:     1954050 = 70 * 15 * 1861
	   Geometry: 2050125 = 71 * 15 * 1925

	Now it gets more interesting.  The value for the C partition
	makes no sense at all.  It doesn't even divide up into an
	even number of 8 KB file system size blocks.  We'll ignore
	it for now and submit an SPR later.  The value for chpt(8) is
	much more interesting.  If we assume that we keep the same
	number of surfaces for data, then we have a disk with 70
	sectors per track and 1,861 tracks.  We already have a plausible
	explaination for the 70 vs. 71.  I guess the missing cylinders
	are cause for another SPR.

	If somebody has a better explaination I'd like to hear it.

	(*) Clearly, we don't want to completely factor the numbers,
	just find any factors that could part of a disk geometry.

	p.s.  It's worth noting that this exercise tends to work
	out for DSA disks.  We typically use one or two sectors
	on each track for BBR, but have the track size show up one
	or two shorter.  The exception of which I know is the ESE20
	that has 3 less sectors than the geometry indicates.  The
	ESE20 is a solid state disk with a data retention system.
	The three sectors are used to construct an replacement
	control table to keep all the DSA disk controllers happy.

-- 
Alan Rollow				alan@nabeth.cxn.dec.com