lkml.org 
[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Drive name slips...
Horst von Brand writes:
> "Khimenko Victor" <khim@sch57.msk.ru> said:
> > Horst von Brand (vonbrand@sleipnir.valparaiso.cl) wrote:
> > > Chris Meadors <chris@hereintown.net> 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.

I agree. SGI agrees. It's on my ToDo list.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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