Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
Was this post just not interesting enough, or is it the lack of access to
hardware
to test this on that prevented it from being picked up by someone?
see google, for example: http://christophe.varoqui.free.fr/multipath.html
While that information is accurate, it is not new to me.
I must have been unclear in my description of how the scsi device registration
with the kernel causes multipath devices to function inefficiently.
When a device has multiple paths, the kernel will see multiple scsi devices,
even
though there is only one physical device. For each of the scsi devices that the
kernel can see, the partition table (or some other IO that I am unaware of) is
read from the device, meaning IO is generated on ALL paths to the device. This
isn't
a problem for some devices, but on others it can initiate a failover process
which can
take many seconds, only to have the process repeated as IO is generated on a
third path to
the device.
Is it unreasonable for the scsi initialization routines to be aware that some
kernel scsi
devices are really the same physical devices and register them with the kernel
WITHOUT
generating any IO on the physical device?
Doing this there would be a maximum of one failover per physical device durint
the boot
sequence. This one failover could be eliminated if the scsi initialization code
were aware
of "active" paths and only generated IO on active paths, rather than the first
path.
All of this is before device mapper or multipath get thier hands on the scsi
devices. It is
completely within the scope of the scsi initialization code in the kernel.
Is this more clear? If not, could someone ask for clearification of the fuzzy
parts?
Evan.
-
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/
