Re: SCSI init discussion/SAN problem (not interesting)

[Evan Rempel]

Bernd Eckenfels wrote:
> In article <456B8EBC.7070801@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/