Messages in this thread | | | Date | Fri, 18 Feb 2000 07:02:27 +1100 | From | Richard Gooch <> | Subject | Re: 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/
| |