/etc/diskpart
John P. Linderman
jpl at allegra.UUCP
Fri Apr 19 07:08:53 AEST 1985
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
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list