Adding/setting up mem, disk, cd drive, sys admin?
Alan's Home for Wayward Notes File.
alan at shodha.enet.dec.com
Sun Jun 16 15:11:28 AEST 1991
In article <44675 at netnews.upenn.edu>, lau at 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 at nabeth.cxn.dec.com
More information about the Comp.unix.ultrix
mailing list