I'll add that throughput is higher with FCP, and CPU utilization is lower, due to the DASD driver overhead not being there for FCP.
Take a look at this presentation by Volker Sameske at IBM: http://linuxvm.org/present/zSeries04/L96.pdf On the downside, path failover is a bit of a pain to implement with FCP. That is a rock solid feature of FICON, especially under z/VM. An additional cost for you might be the cost of a Fibre Channel switch, if you do not have access to one currently. You cannot connect directly to FCP devices (and probably would not want to); you must be in a switched fabric environment. As David pointed out, an existing FICON card can be converted to FCP with a microcode load and a change to the HCD/IOCP. Scott Ledbetter StorageTek -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Sunday, March 06, 2005 8:16 PM To: [email protected] Subject: Re: Ficon vs FCP for Shark 800 > In this "mainframe only" environment, is there any reason to configure > the Shark to have SAN capabilities and then connect the Linux to it > via the FCP channels? Yes. Biggest reason -- large volumes (like >100G) for database and other purposes. You can simulate them with LVM, but it's much more complicated, and it's one less "different" thing about Linux on the mainframe to have your Intel weenies whine about. It also allows your Linux system to get at other non-disk devices (like tape drives -- why put up with 40G on 3590s? Get 200G/volume on cheap LTO or DLT drives, especially if you've already paid for them elsewhere on the SAN). Backing up your Linux system is a lot easier if you can present SCSI drives. > 1. Cost. I already have to have the FICON channels for the 390 side. > To support FCP, I have to also buy the FCP cards. Although for the price of a spare FICON card in the 800, you can also connect to LOTS cheaper FCP storage devices for a lot of your disk needs -- like all that extra space the Intel weenies bought -- and save the Shark for the stuff that HAS to be CKD (like VSE guests, etc). The FICON cards in the 800 are the same as the FCP cards -- it's just different microcode in the card. Or if it's only Linux and z/VM 5, skip the FICON and go FCP for the whole thing. > 2. Flexability. If all the Shark is configured for the mainframe > side, then dasd can be assigned in cylinder increments to whatever > side needs > it. I think Shark LPAR divides things up on 8-pack increments. (or > maybe twin 8-pack increments) If you can potentially use it for other systems too, then they can contribute to paying for it...8-) > 3. Management. Only have one side to manage. See above. > 4. Flash Copy. I'm not sure that flash copy is available on the FCP > attached side. But if it does, then I may need extra space for flash > copy images. (Flash Copy with copy only, doesn't copy all the data, > just the data that is changed. This can result in quite a reduction > in space need for the flash copy, copy.) Dunno about this one, but it's awfully nice to be able to steal disk from the open systems weenies now...8-) ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
