>Brian Buhrow bellowed:

> Actually, I use disktab(5) files to document the size, geometry and
>partitioning of the drives I install on various systems.  I have a master
>file which I ammend everytime I get a new drive that I want to use with
>NetBSD.  this allows me to document drive partitions in one central place,
>as well as restore labels that get corrupted by errant writes.  It's also

Exactly!  Though I haven't considered tracking actual partitions.
Partly because a given disk (model) may be used in different
ways on different machines.  Of course, the obvious way to do
this is embelish the identifier field:

XYZ 2G on Fred
XYZ 2G on Barney

etc.

>useful for drives that are used in raid configurations.  If I use the same
>label on all drives in the raid, I can be sure that as drives where out and
>are replaced, I don't have to worry about going back and reinventing the
>wheel with respect to the partitioning and/or geometry.

Ah, good point.  So far, what I have done is roughly:

# disklabel xx > foo
# disklabel -R yy

>It may be that there is no need to keep a central disktab(5)
>database which is distributed with the NetBSD software, but to
>say that disktab(5) is useless and that its functionality serves
>no purpose is completely missing the point for potential large
>institutions which might have numerous instances of a given
>drive type/partitioning scheme.