Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs.4bsd
Subject: /etc/diskpart
Message-ID: <3679@allegra.UUCP>
Date: Thu, 18-Apr-85 16:08:53 EST
Article-I.D.: allegra.3679
Posted: Thu Apr 18 16:08:53 1985
Date-Received: Fri, 19-Apr-85 01:03:25 EST
Distribution: net.bugs.4bsd
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 48

How many bad sector tables does a cylinder occupy?  If that sounds like a
strange quantity to you, I can only agree.  It is nevertheless calculated
by /etc/diskpart, probably because the arguments to howmany() were
reversed in
    threshhold = howmany(spc, badsecttable);
Swapping the arguments to figure how many cylinders a bad sector table
occupies makes a little more sense.  But there is really no harm in
having a file system and the bad sector table share a cylinder, as long
as they don't share any sectors, so the calculation will be too
conservative, even if the the howmany() arguments are straightened out.

My real gripe with diskpart is not the minor flaw in calculating bad
sector table space requirements.  The real gripe is that diskpart only
tells me about DEFAULT partitions for entries in /etc/disktab, while
newfs uses what is really STORED in /etc/disktab.  Lest you think they
are always the same, here's what a modified version of diskpart told
me about the information actually present for RA81's in our original
/etc/disktab:

f partition overlaps bad sector table
g partition overlaps bad sector table
ra81: #sectors/track=51, #tracks/cylinder=14 #cylinders=1248

    Partition	   Size	   Range	Unused
	a	  15884	   0 - 22	   538
	b	  33440	  23 - 69	   118
	c	 891072	   0 - 1247	     0
	d	  15884	1134 - 1156	   538
	e	  55936	1157 - 1235	   470
	f	 478582	1236 - 1906	-470218
	g	  82080	1134 - 1248	  -888
	h	 759668	  70 - 1133	    28

Partition g extends one cylinder beyond the end of the disk, and
partition f is mostly off the end of the disk.  Ignoring the issue of
how such numbers got into /etc/disktab to begin with, the point is that
the original /etc/diskpart would never warn you that something was
rotten.  I added a -o option to diskpart to o-verride the defaults and
report what is actually in /etc/disktab, which is where the figures
above came from.  The diffs are so extensive that posting them would be
tantamount to posting the source.  Those with access to 4bsd bug
reports can find the source there.  Maybe it'll see the light of day
in some future release.  Others should at least be aware that
/etc/diskpart only dimly reflects the contents of /etc/disktab, and
that updating /etc/disktab and then running diskpart to generate new
kernel tables is almost certain to result in disaster.

John P. Linderman  Diskpart Deportment Department  allegra!jpl