[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Drive name slips...
"Khimenko Victor" <> said:
> Horst von Brand ( wrote:
> > Chris Meadors <> said:
> >> "Raj, Ashok" wrote:

> >> > Linux kernel names the scsi drives sda, sdb .... so in case you switch
> >> > slots, or move across to a different controller then its possible you
> >> > can have very bad effects. Worst case is removing a drive and the drive
> >> > device files dont have a persistant assiciation with the location, or
> >> > do we have a magic superblock what the configured name was.

> > [...]

> >> devfs takes care of this. With the devfs patches you can address your
> >> drive by it's physical location, from controller all the way down to
> >> partition.

> > That is exactly the wrong answer.

> This RIGHT answer. Or rather "this is right half of answer". See below.

> > What is needed is to address the _data_ on the disk, not it's ephemeral
> > phyiscal location.
> And what you can do if you DO NOT KNOW ENOUGH to address _data_ on the disk ?
> How you can mount MO or ZIP this way, for example ? You should write label
> on every ZIP and every MO-disk ??? Gosh.

What the user wants is to get at her data, not what happens to sit on
/host/ide0/disk0/p5 today. Sure, when disks are fixed it is convenient to
mount this stuff somewhere and give a system internal name to this, like
/home/jane. This association between data and system internal name is set
up by the sysadmin and set in stone. This is the hardware on which Unix
grew up, and Linux follows its lead. Problems arise when disks aren't fixed
(removable media, like floppies et al) or even data is distributed around a
net. DOS (and Windows) grew up in a world where nothing was fixed, their
model of handling data is different. But getting the model right is _hard_
(they do it a tad better than Unix, but not by much), doing it efficiently
might well be impossible. Latest Wins work mostly the Unix way too.

What you say is definitely a problem. But we have to come up with a natural
model for addressing _data_, not "the data that right now happens to reside
on device this or that"

> > Worse yet, having to become acquainted with esotherica like "controller
> > all way down to partition". OTOH, if you take a look at current
> > versions of mount(8), you _can_ mount by volume identifier and don't
> > need all this nonsense at all.

> Ok. HOW, JUST HOW you can mount by volume identifier when you just DO NOT
> KNOW that volume identifier ? Typical situation for removable media by
> the way. Of course in perfect world every such medium will have label
> printed in that medium... We live in real world, unfortunatelly... I've
> NEVER seen CD's where information about label is printed on cover: you
> should mount it to find out. And with you proposam you should ALREADY
> know what's number is to mount it...

You can read the medium to find out what is on it, and have the system keep
that information somehow. We are talking about some sort of database that
keeps track of this information for you. Today it is called /etc/fstab.

Note that I'm not talking about how we could do this today, but where we
should be going, perhaps in the somewhat distant future.
Horst von Brand
Casilla 9G, Viña del Mar, Chile +56 32 672616

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.064 / U:32.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site