> > Dave Barr <barr@math.psu.edu> writes:
> >
> ....
> > > If we do that, we _definately_ have to adopt something like the
> > > Solaris /dev/dsk/c0t0d0s3 scheme. It gets really tiring trying to out-
> > > guess what the kernel is going to name a new disk when it's put online.
> >
> > On Mon, 5 May 1997 19:31:44 -0400, Theodore Y. Ts'o wrote:
> >
> ....
>
> > >I had always thought that the right approach would go far beyond
> > >scsidev; if you have a volume management daemon that would automatically
> > >do the right thing based on the volume ID (pretty much all filesystems
> > >have them now: ext2, iso9660, even MS-DOS FAT), then who cares what the
> > >device name is?
> >
>
> Although both approaches have their advantages, I agree with the latter.
> Require a unique "volume label" for each filesystem and use it for the
> device name: /dev/dsk/"volume label".
>
> This is the Data General approach in dgux. The only disadvantage is
> that
> if you do a complete copy, or break a mirror, your volume label is not
> unique any more. DG does provide a way out, I believe they also put a
> serial number on each slice.
I would tend to think that using both schemes wouldn't be so bad. I like
the Solaris approach for it's "elegance", but Naming the partitions
using the volume label seems much more practical in most cases. The most
obvious problem with that I can see is that your CD-ROM's label would
change constantly.
Maybe if the kernel created the volume ID names as sym-links, so that
you could also easily tell where that drive was just by looking at them.
--
Chris Arguin | "...All we had were Zeros and Ones -- And
cpa@hopper.unh.edu | sometimes we didn't even have Ones."
+--------------+ - Dilbert, by Scott Adams
http://leonardo.sr.unh.edu/arguin/home.html |