On Oct 2, 10:03pm, Greg A. Woods wrote:
} [ On Sat, October 3, 1998 at 02:40:30 (+0100), Roger Brooks wrote: ]
} >
} > Yes, but you can (and should) change the SCSI ID *before* you connect the
} > disk to your system.  But what if you want to attach a disk with a label
} > which collides with one on an existing disk.  Suppose you want to connect
} > the system disk of a non-working machine to another system so you can examine
} > it and work out what's wrong, and both are labelled "NetBSD_1.3.2".
} > You can't change the label until you've connected it, and you can't connect
} > it until you've changed the label.  You're stuffed!

     I've been thinking about this issue of disk labels and I think
I've come up with something that just about everybody would like, and
which core would probably approve.  For my scheme to work, there needs
to be a place to store a (potentially) unique label on a disk.
d_packname in the disklabel serves this purpose nicely, which means
that no kernel changes are required at all.

     The basic idea that is that if somebody does "mount -l <label>:x"
then the mount program would look at all the incore disklabels
(possibly reading labels from removable media) and look for <label>.
If mount finds <label> on more then one disk, then it should abort
with an error, and the user will have to revert to the old method of
specifying the device.  If it only finds <label> on one disk, then it
figures out the corresponding device and passes it to mount(2) the
same way it does now.

     The beauty of this method is that it is simple and does pretty
much everything that everybody wants.  It doesn't require any kernel
modifications; it only requires fairly simple changes to one program
and its accompanying documention.  It doesn't have any backwards
compatibility problems, nor does it force any changes in the way
things are done now; it merely adds new functionality, without adding
a significant amount of bloat.

     This idea could be extended by extending the syntax of fstab so
that label could be used there, and/or by adding library routines to
make it easy to mount/open disks using labels from within programs.

} In theory the driver should reject making devices available which have
} clashing d_packname's, but it should *never* prevent you from reading
} the label manually and manually blasting a new label onto the drive.
} 
} I.e. open(/dev/rsd0a) == ENXIO for both disks which clash, but opening
} the default "full-disk" partition, or more specifically the "raw" disk,
} aka open(/dev/rsd0), works fine.

     Why?  If somebody specifies the actual device then the contents
of d_packname is irrelevant.

} Of course in the stupid world of the averate x86 PC BIOS you might also
} want a device node that represents the "unix" fdisk partition so that
} you can treat it as a logical volume and drop a normal disklabel into
} it.  This would imply that one could have four (isn't that the fdisk
} table size?) "unix" partitions and at least 8 filesystems per logical

     Yes, not counting extended partitions, which does complicate
matters somewhat.

} volume, thus a median of 32 filesystems per spindle.

     This is one of the few places where I actually agree with you.
The ability to access MS-DOS type partitions would be really nice.
FreeBSD has a method of doing this.  Linux simply uses MS-DOS
partitions and doesn't have a disklabel of its own.  I don't know
about OpenBSD.  When you only have five NetBSD partitions to use,
having to burn one to represent your MS-DOS partition really sucks.
It's even worse considering that its redundant and must be very
carefully synchronised manually.

     Charles did propose a solution to this problem a while ago, but I
think his solution is too complex and prone to problems.  It required
ALL partitions to be setup and map by a program, instead of being
automatically done by the kernel.  This is a disaster waiting to
happen (just ask any HP-UX admin).  I think something more akin to the
FreeBSD method would be better.  Of course, we would have to come up
something that would work nicely on platforms besides PC's, i.e.
Amiga's and Mac's.

}-- End of excerpt from Greg A. Woods