I had a mail exchange with gooch. devfs does solve the problem for todays
local drives
and controllers. whereas the problem comes up when your discovery order
changes.
eg: you have a controller on a SAN, and say host monitors and gets the
controllers in a different order, devfs will also switch since now the
host0, host1 etc are not the same as last reboot.
the issue also exists for new hot plug PCI, if i add a additional s pci scsi
card, the next scan may give it a different discvery order. Beleive for some
reasons like that,
solaris for eg: have complete paths including bus, dev etc in the devfs
path.
I would also like to thank Richard Gooch for his clean cur unamiguous
answers.
Its a lot of good work that needs to get in main kernel soon.
-----Original Message-----
From: Khimenko Victor [mailto:khim@sch57.msk.ru]
Sent: Thursday, February 17, 2000 3:54 AM
To: vonbrand@sleipnir.valparaiso.cl; chris@hereintown.net
Cc: ashok.raj@intel.com; linux-kernel@vger.rutgers.edu
Subject: Re: Drive name slips...
In <200002170310.e1H3AXL29880@sleipnir.valparaiso.cl> 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.
> 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...
P.S. When you know UUID it's can be enough. You just not always have such
information...
-
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:20 EST