Greetings and Flatulations!

> der mouse bellowed:

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


Yes, but you are counting on having the drives on a box that
has NetBSD (etc.) installed.  Or, schlepping the (external)
drive over to such a box.

Figuring out what capacities the various drives I have in
machines here would require dragging them out of storage
(for some machines) and *hoping* that whatever OS was
on the machine would conveniently report this to me.  Of
course, this also means dragging out a monitor, keyboard, etc.
Or, scribbling on the case and then just *finding* the machine
and looking for said label...

I find it much easier to just compile the information in
one place where I am *likely* to go looking for it.
disktab(5) seems as good a place as any!

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

Ah, I have a bit more variety -- and far fewer brain cells that
I would like to commit to that activity!  :>

>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've done likewise -- except it now sits in disktab(5) instead
of on the physical drives themselves.  (I've also noticed that
adhesive labels here tend to dry out and fall off things!)

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

I run a variety of machines and OS's.  And I don't like having
to clutter up my head remembering which tools I need to use
to get at "basic facts".  I keep (handwritten) log books but those
are notoriously difficult to search!  :-/

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

Yeah, but that means disassembling the machine just to pull
the drive!  Sticking it in an enclosure (or otherwise jerry-rigging
power to it) and then probing it -- only to reverse the process
when you're done!

When I purchased the SPARCs, I needed to figure out where to
"allocate" drives from.  Having a record of each drive's
size/geometry (in disktab(5) on a FreeBSD box at the time!)
made it a lot easier to sort things out!

Of course, I *could* use a pencil and paper but I *know* that
will get misplaced...

>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

Yes.  And the average is usually not an integral value.

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


This is the essence of my query regarding how important geometry
and "sectors per unit" are to the OS!

If, for example, the OS only cares about sectors per unit, then
putting *anything* in the other fields should be acceptable,
right!  I.e. 1C/1H/1S should work for *all* disks!

If, on the other hand, the OS prefers the geometry information
to the actual drive capacity, then you want to ensure that
CHS figures are as close as possible to the actual capacity
(without exceeding it -- since the assumption in this
paragraph is that the OS *cares* about the geometry!).

In the latter case, create a *fictional* geometry
by factoring the "sectors per unit" capacity figure into
"appropriate" CHS figures to suit your tastes -- knowing
that regardless of whether the OS looks at the "su"
parameter or the "n[sct]" parameters, you are "safe"
(counting on the drive to do translation for you)

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


--don