With the current LABEL= support, you won't be able to mount the disks with
duplicate labels, but you can still mount them via /dev/sd<xxx>. Obviously,
you need an escape hatch to do this. I ran into this with having two root
partitions (to support multiple distributions or releases of distributions),
where the distribution automatically uses LABEL=. Fortunately, it was fairly
easy to use e2label to fix things up.
> > This is the problem with all sorts of ID-based naming. In this case
> > the kernel could simply change the conflicting names a bit,
> > and leave the cleanup to the administrator. (Who probably
> > is around as he just inserted those disks....)
> > The current scheme have problems if you move a disk
> > from one controller to another, or in some cases
> > if you merely add a new one. So the question becomes -
> > what is most likely to go wrong? And you can be
> > smart and name your partitions /usr21042001, /home03042001
> > and so on in order to minimize the risk of conflicts.
> Well, a usermode solution might be to add support for having the
> filesystem utilities generate and detect partition IDs. Then the disks
> could be moved from one controller to another, but mount could scan
> partition IDs and associate mount points on matching IDs rather than on
> /dev/hdX or /dev/sdX.
I don't see how this is any different from the current LABEL= support that is
currently in the ext2 filesystem (except I seem to recall that it doesn't work
on devfs). Of course it would be useful for /proc/partitions to provide the
label IDs and UUIDs.
-- Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: firstname.lastname@example.org phone: +1 978-486-9304 Non-work: email@example.com fax: +1 978-692-4482 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/