Subject: Re: disktab(5)
To: None <port-sparc@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 11/27/2001 10:58:39
>>> 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