Greetings!

> Brian Seklecki exclaimed:

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

OK, quick... how many sectors on a 1.4M floppy?  what about
those ZIP drives?

And, if you claim it is only useful for these "legacy" drives,
how many sectors on that brand new 879GB SCSI-3 drive you just
bought (:>)?


What about those wonderful spec sheets that just tell you
the drive's capacity -- in bogus units like "MB"  (is a MB
1,000,000 bytes or 2^20 bytes?  It varies!!)?  So, you figure
it out sometime because you *need* to know -- now where do
you *remember* that?

The point is, how do *you* keep track of your drives?  I just
did a quick mental count and figure I have at least 20 different
drives in use here *now*.  That doesn't count things like
various floppy disk formats, etc.

I keep pretty good documentation on all my equipment -- but it's
a royal pain to have to trudge out to the garage to dig out a
spec sheet for some drive just so I can plan how I intend to
use (e.g., partition!) it.

The alternative, of course, is to hope that whatever device it
is connected to has the capability of providing you with this
information "on demand".  Hmmm... does NetBSD's sd(4) probe
report things the same way that FreeBSD does?  What about
Mac's?  Or (shudder) Pea Sea's?

Disktab is a great place to keep track of this sort of stuff.
The *unuseful* part of disktab is all the partition related
stuff -- the fields/capabilities that I mentioned previously.

I can also argue that the actual geometry information (not
just the total device capacity) is useful as some OS's
expect partitions to end on cylinder boundaries, or allocate
a certain number of spares *per cylinder*, etc. (i.e. 100S/5C/2H
sets aside more spares than an equivalent capacity 10S/50C/2H
geometry).

IMHO, seems easier to use an existing "database" to track
this sort of stuff than inventing something equivalent
(pencil and paper??  :>)

But, I've been accused on several occasions of being too
compulsive about these sorts of details... :>

--don

>>     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"?)