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

Yes.  This technique may not be suitable for everybody, but that's how
I do it, that's my answer to your question. :-)

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

I suppose, though that helps only with giving you capacity and geometry
info for a disk type - it doesn't keep inventory for you, which at
least for me would be the larger task.  Or, to put it another way...

>> I have a number of drives that are sitting idle; I [...] put a
>> yellow sticky note on each one with the size and a few-word summary
>> of what was there.
> I've done likewise -- except it now sits in disktab(5) instead of on
> the physical drives themselves.

...how do you tell "ST12400N with partial alpha install on it" from
"ST12400N with Sun label and empty fs" in disktab?

>> (The value a drive reports for sect/track is usually an average
>> obtained by dividing the total size by the cylinder and head
>> counts.)
> Yes.  And the average is usually not an integral value.

True.  But believing it generally loses you only a comparatively small
amount of space, in my experience.

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

Yes.  Except that's not quite the case - close, but not quite.

With SCSI disks, I've always found it works to put nhead=32 sect/trk=64
in the label, which gives 1M "cylinders"; it has occasionally been
convenient to have all my disks partitioned up in chunks of the same
size.  This is what I do with all my NetBSD-only SCSI disks[%]; I've
done it under SunOS and find that if I set the cylinder count the way I
usually do (rounding up the partial "cylinder" at the end), the kernel
whines at boot time but everything works.  NetBSD doesn't even whine.

[%] I have one that as yet has to coexist with another OS, because
    NetBSD/mac68k is not 100% self-hosting in the version I have; I
    need a MacOS partition to bounce off of at boot time.

IDE disks, as I said, I don't try to meddle with; there's too much
magic I don't understand going on.

>>> Then how does the driver know:
>>> - where partitions begin and end
>> The label, which it reads off the disk (usually sector zero) when
>> the drive is first accessed.
> Yes, but the label also contains geometry information.  Are you
> claiming that this is *ignored*?  I.e. could I scribble "0"s in all
> the fields and not notice *any* side-effects?

No, I'm not claiming that.  As I explained, FFS filesystems have
geometry information in the superblock; by default, newfs copies this
out of the label at filesystem create time.  (newfs has options to
override the label's geometry info; if you use enough of them, the
label's geometry _is_ ignored.)

On some ports, the label geometry information may be used to compute
partitioning info; Sun-compatible disklabels, for example, keep
partition beginning points in units of cylinders, not sectors.  (Some,
but not all, NetBSD versions also keep a BSD disklabel around, so that
only your boot partition is really affected by this.)

>>> - where to "avoid"
>> Huh?  I don't know what you're referring to here.  Perhaps I'm just
>> misinterpreting your smiley....
> I was referring to the partition table.

See bounds_check_with_label(), which is designed to keep you from
accidentally overwriting the label.

> And, also, the "magic" that causes the drive to avoid "sector 0"
> regardless (???) of which partition it appears in.

I don't know what magic you're referring to here.

> I.e. placing a BSD partition at "0" *or* SWAP at "0"!  (or, is this a
> mistake waiting to happen?)

FFS does not use the first 8K of a filesystem, apparently specifically
so that you can put an FFS filesystem at offset zero and not thereby
wreck your label/bootblock area.

Putting swap at offset zero, yes, is asking for trouble.  I think
bounds_check_with_label will catch this, unless you swap on RAW_PART,
in which case you presumably don't care about having a label.

>> At the filesystem<->driver interface, the drive is just a big linear
>> array of blocks.

>> Below that, it depends on the interface.  SCSI disks are addressed
>> by sector number.  IDE disks may or may not be; I think this is LBA
>> addressing versus CHS addressing.
> But, if CHS addressing is used, then the geometry is significant.

True.  But I don't know which geometry it is that matters; I'm inclined
to doubt it's the disklabel geometry, but I haven't dug around to see.

> So, back to my original question:  does *anything* look at the CHS
> figures in the drives geometry (as carried in the disklabel -- which
> brings us back to the disktab issue)

newfs, as I explained, does, though it has overrides.  Quite likely
other similar programs for other filesystems are similar, though I
don't know definitely either way.

Everything else, as far as I can tell, is port- or hardware-specific;
in some case the answer is "yes"; in some cases I think it's "no".
(I'm sure of one "yes", I'm fairly sure of one "no", and I have strong
suspicions that two others are "no"s.)

/~\ 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