jpl@allegra.UUCP (John P. Linderman) (04/18/85)
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!jpled@mtxinu.UUCP (Ed Gould) (04/23/85)
> 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. ... The first line of diskpart(8) reads "Diskpart is used to calculate the disk partition sizes based on the default rules used at Berkeley." It's intended use is to generate the first cut at both the disktab and kernel driver entries, not to *report* the state of either. -- Ed Gould mt Xinu, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146
jpl@allegra.UUCP (John P. Linderman) (04/25/85)
> The first line of diskpart(8) reads "Diskpart is used to calculate the disk > partition sizes based on the default rules used at Berkeley." It's > intended use is to generate the first cut at both the disktab and > kernel driver entries, not to *report* the state of either. And the second line reads ``If the -p option is supplied, tables suitable for inclusion in a device driver are produced.'' My interpretation of ``suitable'' would include a reasonably close relationship between the contents of /etc/disktab [which, while we are quoting chapter and verse, ``describes disk geometries and disk partition characteristics,''] and the kernel code that supports the device. While I agree with the comment in disktab(5) that the proper place for the information is on each pack, we aren't there yet. Where we are has newfs reading all the entries in disktab, diskpart reading some of them, and the kernel code reading none of them, with conspicuous opportunities for disaster. I don't know what the ``intended use'' of diskpart is, but anyone wishing to see what newfs is really going to do, or anyone wishing to generate device driver tables to support a new drive or a new partitioning of an old drive, has a use for a utility that looks carefully at the contents of /etc/disktab. There is good reason to make this the same utility that understands the default rules, because one would like to do something intelligent (or at least consistent) if partition size information is left unspecified. So I ``fixed'' diskpart by adding an option to meet those needs. I suppose it is impossible to introduce any change whatsoever without offending someone's sense of aesthetics. John P. Linderman Department of diskpart deportment allegra!jpl
gnu@sun.uucp (John Gilmore) (04/30/85)
> While I agree with the comment in > disktab(5) that the proper place for the information is on each pack, > we aren't there yet. Sun did this on all our systems; maybe Berkeley will buy back the changes for 4.3. Note that this requires changing the bootstrap code. I don't know how tight on space their boot code is; at times we've had to hack and squeeze to make it fit.