I think I speak for everyone when I say that disktab(5) is useless.
Nothing/nobody uses it anymore.  It's for legacy drives.  I think I
submitted a PR and sent an e-mail asking to put ZIP100 and ZIP250 SCSI
entries in there, but never heard anything back (for obvious reasons)

-lava

On Mon, 26 Nov 2001, Don Yuniskis wrote:

> 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
>
>
>

--Brian

 ----

"GNU/Linux: About as stable as the elements at the bottom of the periodic
table"