lkml.org 
[lkml]   [2001]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LANANA: To Pending Device Number Registrants
On Wed, May 16, 2001 at 09:30:46AM -0700, Miles Lane wrote:
> On 16 May 2001 15:28:03 +0200, Helge Hafting wrote:
> > Oystein Viggen wrote:
> > >
> > > Quoth Helge Hafting:
> > >
> > > > This could be extended to non-raid use - i.e. use the "raid autodetect"
> > > > partition type for non-raid as well. The autodetect routine could
> > > > then create /dev/partitions/home, /dev/partitions/usr or
> > > > /dev/partitions/name_of_my_choice
> > > > for autodetect partitions not participating in a RAID.
> > >
> > > What happens if I insert a hard drive from another computer which also
> > > has partitions named "home", "usr", and soforth?

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: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.131 / U:1.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site