Subject: disktab(5)
To: Port-SPARC <Port-SPARC@NetBSD.org>
From: Don Yuniskis <auryn@gci-net.com>
List: port-sparc
Date: 11/26/2001 17:04:29
Greetings and Elongations!
     I have been building disktab(5) entries to support the
various drives I have on NBSD boxes, here.  Obviously,
*trying* to do it in a consistent manner with the other
entries therein.
    But, there doesn't seem to be any *true* consistency
among the entries -- I imagine this is due to a slow
accumulation of entries over time instead of a single
concerted effort to create the One True disktab Format  :>

    Does it seem appropriate that entries should *just*
contain those capabilities/fields that are *not* "site-specific"?
In other words, skip the partition information completely
since the user isn't *bound* to use any particular partition
scheme set forth here.
    In particular, skip the [bdfopt][a-h] fields for each entry
and, instead, just concentrate on getting the "right" (ha!)
disk geometry, sector size, etc.?  One could argue that it
*might* be desireable to define *just* the "c" partition
since that doesn't (?) usually change (though doesn't i386
use "d"?)

    Also, shouldn't the "ty" field for SQ555 be "removable"?
<shrug>  Dunno, I don't have one but I would *think* it
is a cartridge style device...

    Lastly, (and this is probably the tricky question!) which
parameters are *required* to be correct?  And, must they be
consistent among themselves?
    For example, does the total number of sectors (su) override
the effective unit size (ns * nc * nt)?  Or, *must* they
agree?
    In more practical terms, if the drive reports N sectors
(and you *assume* this to be Gospel), *must* you define a
geometry that coincides with this; does not *exceed* this;
or, is the geometry largely immaterial?

    I ask since I had problems some years ago under FreeBSD
where the system was using a bogus geometry instead of the
actual geometry.  As a result, the system thought the drive was
bigger than it really was.  Since my swap happened to be
at the end of the drive, the problem would only turn up when
swap was heavily used.  And, of course, this was not
a "graceful recovery"!

--don