So if disktab is to stay, who will maitain it...since SCSI is not an
architecture independant standard, but geometrys tend to vary depending on
the hardware interface.

i.e., will a zip250 or zip100/scsi on a Sun box have the same specs as a
250 ATAPI or USB on i386.

Will there be a different disktab(5) database for each platform?

-lava

On Tue, 27 Nov 2001, der Mouse wrote:

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

--Brian

 ----

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