Yes, hence the recommendation for LVM or RAID-0 as a workaround until such time as PAV support becomes available.
Mark Post -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 1:25 PM To: [EMAIL PROTECTED] Subject: Re: Multipath I/O on 390 Linux Greetings all; But regardless of all these grand features, lacking PAV are we still not limited to ONE i/o operation per os-visible spindle at a time? os-spindle = the physical device address we talk to regardless of VM minidisks or any Shark internal magic. Dennis David Boyes <dboyes@sinenom To: [EMAIL PROTECTED] ine.net> cc: Sent by: Linux Subject: Re: Multipath I/O on 390 Linux on 390 Port <[EMAIL PROTECTED] ARIST.EDU> 05/17/02 08:46 AM Please respond to Linux on 390 Port If we're talking about utilizing multiple channel paths to devices, multipath I/O has been around for ages in the 390 world -- at least 10 years that I can remember, and even earlier with the primary/alternate control unit support (max 2 paths for that far back). It really got practical with the XA I/O architecture when all the gory detail information about paths got moved down into the IOCP layer and the OS no longer had to deal with it directly. There are several layers in the 390 I/O subsystem: devices control units channel paths device numbers The relationship of the first 3 items is handled by the IOCP definitions in the processor element. IOCP describes what devices are connected to what control units, and what channel paths are connected to each control unit. Those combinations are assigned unique device numbers, which is the only thing an operating system sees as devices that it can do I/Os against -- IOCP hides all the details of how the cabling is set up and managed. So, by virtue of using the XA I/O subsystem on the 390, Linux gets multipath I/O for free -- it's "just there". (BTW, a ESS with 16 channel paths is a *very* fun toy. Linux works very nicely...8-)) -- db David Boyes Sine Nomine Associates
