Carsten,
You are not really right. We all are very much used to ESCON/FICON
multipathing being handled by the archtecture, that we are tending to
neglect its presence ;)
-ESCON/FICON-MP is handled by the architecture and IS supported
by Linux
-PAV (parallel access volumes aka multiple devnos for single device)
IS NOT supported by Linux. You might very unlikely be lucky to find it
working properly by deploying our LVM multipathing patches.
-FCP/SCSI-MP will be supported by our LVM multipathing patches.
The LVM -MP patches have lately been posted to the LVM development
mailinglist.
Best Regards
Holger Smolinski
--
Dr. Holger Smolinski, Tech. Planning (Storage I/O) for Linux on zSeries
IBM Deutschland Entwicklung GmbH,Schönaicher Str. 220, 71032 Böblingen
FAX: +49-7031-16-3456, Tel. +49-7031-16-4652
|---------+---------------------------->
| | Carsten |
| | Otte/Germany/IBM@|
| | IBMDE |
| | Sent by: Linux on|
| | 390 Port |
| | <[EMAIL PROTECTED]|
| | IST.EDU> |
| | |
| | |
| | 16.05.02 18:27 |
| | Please respond to|
| | Linux on 390 Port|
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Multipath I/O on 390 Linux
|
|
|
|
|
>------------------------------------------------------------------------------------------------------------------------------|
Hi List-Readers!
The kernel of current Linux-Distributions does not support
muliple pathes to a dasd device at all.
A workaround is to spread the data over multiple devices
using LVM or MD in striping mode. Using the same amount
of devices like the amount of pathes available (or a multiple
of it) should fit best.
This problem is already addressed in the current (experimental)
2.4.17 code.
mit freundlichem Gruß / with kind regards
Carsten Otte
IBM Deutschland Entwicklung GmbH
Linux for eServer development - device driver team
Phone: +49/07031/16-4076
IBM internal phone: *120-4076
--
We are Linux.
Resistance indicates that you're missing the point!
|---------+------------------------------->
| | Michael |
| | MacIsaac/Poughkeepsi|
| | e/IBM@IBMUS |
| | Sent by: Linux on |
| | 390 Port |
| | <[EMAIL PROTECTED]|
| | .EDU> |
| | |
| | |
| | 05/16/02 05:42 PM |
| | Please respond to |
| | Linux on 390 Port |
| | |
|---------+------------------------------->
>
--------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Multipath I/O on 390 Linux
|
|
|
|
|
>
--------------------------------------------------------------------------------------------------------------|
> the OS doesn't need to know about the multiple paths
For high availability, yes. But for performance, I was *under the
impression* that Linux needs to be fooled into using the multiple
paths (haven't been able to confirm this with end-to-end performance
tests). This is done by LVM or raid-tools striping (RAID 0). *As I
understand it* the "fooling" works as follows - when a striped
volume is detected, the Linux kernel will continue with data
transfers before the previous one finishes. Then the multiple
I/O paths to the DASD will be utilized. Actually the first time
I tried a performance test, I saw a small performance gain, but it
was negligible enough to be noise.
The recently I noticed in make menuconfig the setting:
Multi-device support (RAID and LVM) --->
<M> Multipath I/O support
which is not always on. So I'm hopeful for some serious performance
gains using RAID 0 and a kernel with this setting on. Any comments
from performance guys with a better background on this?
-Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
