At 11:23 PM +0200 2001-05-17, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Jonathan Lundell) wrote on 15.05.01 in
><p05100316b7272cdfd50c@[207.213.214.37]>:
>
>> What about:
>>
>> 1 (network domain). I have two network interfaces that I connect to
>> two different network segments, eth0 & eth1; they're ifconfig'd to
>> the appropriate IP and MAC addresses. I really do need to know
>> physically which (physical) hole to plug my eth0 cable into.
>
>Sorry, the software doesn't know that. Never has, for that matter.
Well, no, it doesn't. That's a problem. Jeff Garzik's ethtool
extension at least tells me the PCI bus/dev/fcn, though, and from
that I can write a userland mapping function to the physical
location. My point, though, is that finding the socket is a real-life
problem on systems with multiple interfaces. I don't expect the
kernel to know the physical locations, but the user has to be able to
get from kernel/ifconfig names (eth#) to sockets, one way or another.
Support for a uniform means of doing the mapping, even if it needs
userland help, would be good.
> > (Extension: same situation, but it's a firewall and I've got 12 ports
>> to connect.) (Extension #2: if I add a NIC to the system and reboot,
>> I'd really prefer that the NICs already in use didn't get renumbered.)
>
>Make your config script look at the hardware MAC addresses. Those don't
>change.
They're not necessarily unique, though.
> > 2 (disk domain). I have multiple spindles on multiple SCSI adapters.
>> I want to allocate them to more than one RAID0/1/5 set, with the
>> usual considerations of putting mirrors on different adapters,
>> spreading my RAID5 drives optimally, ditto stripes. I need (eg) SCSI
>> paths to config all this, and I further need real physical locations
>> to identify failed drives that need to be hot-replaced. The mirror
>> members will move around as drives are replaced and hot spares come
>> into play.
>
>Use partition UUIDs, or SCSI serial numbers, or whatever. This works
>today.
This pushes the problem back in time: I need to write the UUID, for
example, at some point. And, with hot-swappable drives, I'm still
interested in the physical location. I really know know that there's
a good answer to this problem, especially with FC, but I need to tell
an operator, "replace this particular physical drive". It doesn't do
any good to tell the operator the UUID.
> > Seems like more that merely informational.
>
>The *location*? Nope. Some unique id for the device, if available at all:
>sure.
What good does it do to tell an operator to connect a cable to a MAC
address? Or to remove a drive having a particular UUID? If it's "mere
information", it's *necessary* mere information.
> > (A side observation: PCI or SCSI bus/device/lun/etc paths are not
>> physical locations; you also need external hardware-specific
>> knowledge to be able to talk about real physical locations in a way
>> that does the system operator any good.)
>
>And those you typically do not have.
But (ideally) should.
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
