Subject: Re: disktab(5)
To: None <port-sparc@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 11/26/2001 22:24:27
> OK, quick... how many sectors on a 1.4M floppy?

2880, if you use the 512-byte abstraction sectors.  ISTR reading that
floppy secturs are really 256 bytes, but I don't know the truth of it.

> what about those ZIP drives?

The "100MB" ones are exactly 96MB, in my experience, meaning 196608
512-byte sectors.  The "250MB" ones I've never worked with, but I would
semi-expect them to be 240 (2.5*96) MB, for 491520 512-byte sectors.

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

Not unless you're a disk manufacturer; nobody else uses metric
megabytes.  I've occasionally wondered why they don't quote in terms of
"1MB = 900,000" bytes; it'd make their numbers sound even larger.
(I've also entertained daydreams of buying a memory manufacturer so
that upon receiving an order from a disk manufacturer for (say) a 256MB
stick of memory, I could ship them one with exactly 256,000,000 bytes
of storage.)

> So, you figure it out sometime because you *need* to know -- now
> where do you *remember* that?

In my experience, the drive remembers it for me and tells the kernel at
boot time.

sd0: 4095 MB, 3992 cyl, 19 head, 110 sec, 512 bytes/sect x 8386733 sectors

sd1: 4357 MB, 8387 cyl, 5 head, 212 sec, 512 bytes/sect x 8925000 sectors

sd2: 2048 MB, 2621 cyl, 19 head, 84 sec, 512 bytes/sect x 4194685 sectors

sd3: 2048 MB, 2621 cyl, 19 head, 84 sec, 512 bytes/sect x 4194685 sectors

> The point is, how do *you* keep track of your drives?

What track needs keeping?  Most of my machines have one drive of
approximately 1G each; the two or three that don't I manage by wetware.
I don't think disktab would keep any info the drive doesn't report at
boot time for any of them, with the possible exception of partitioning,
which is also kept on the drive.  I have a number of drives that are
sitting idle; I went through them, connected them up, looked at what
was on them, and put a yellow sticky note on each one with the size and
a few-word summary of what was there.  "1010MB, ancient alpha install".
"1030MB, corrupt pmax boot disk".  "864MB, sun label, empty fs".

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

Hm, I usually just connect it up and see how big it is.  I'll often
label and partition it then too, before putting it on the target
machine.

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

I suppose.  But I've never had that hope fail to be realized yet.  (Of
course, I also don't run anything but NetBSD, except for one legacy
machine.)  And I've no reason to think I'm likely to get any drives
that a NetBSD box won't probe usefully.

> Hmmm... does NetBSD's sd(4) probe report things the same way that
> FreeBSD does?  What about Mac's?  Or (shudder) Pea Sea's?

Does it matter?  Not to me: put the mystery drive on a NetBSD machine
and it self-reports fine, has been my experience.  If/when that fails,
I may have to do something more elaborate.  But until then, all the
drives I have keep track of themselves just fine.

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

True, but "actual geometry information" simply does not exist these
days except per-notch.  (The value a drive reports for sect/track is
usually an average obtained by dividing the total size by the cylinder
and head counts.)  Usually, the OS requires partitions to begin &c not
on actual cylinder boundaries but rather on multiples of the label's
(sect/trk)x(trk/cyl) product.  Making the label geometry match the
physical geometry, besides being impossible except for one notch, is
mostly pointless, since most of the things OSes care about geometry for
are pointless or counterproductive on modern drives anyway.

Not that any of this is a reason you shouldn't keep track of whatever
info you want about your disks wherever you want, including your
/etc/disktab. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B