my 2 cents...

> PROS:
> Really really big LUN sizes ( much larger than 3390-9 or -27 )
right, though one could use LVM to create large disks out of of many
smaller ones (downside would be overhead and additional work)

> LUNs appear as regular scsi volumes eg: /dev/sda
well, please try to use persistent device name whenever possible
because this enumeratiion sda, sdb, sdc... might cause device
name slippage
(persistent names come with SLES9, some workaround available
for RHEL4; if you need details, don't hesitate to ask...)

> LUNs can reside on basically any SAN storage on the network, can use
much
> cheaper disk than traditional ECKD type
that's true - as an IBMer I would recommend FastT then, but you
might have though about something else ;)

some other pros':
+ performance seems to be superior for certain types of workload
(http://www-128.ibm.com/developerworks/linux/linux390/perf/index.html)
+ IBM has got all the pieces in place for a SCSI based tape backup
solution (Tivoli uses SCSI tapes)

> CONS:
> Multipath is not trivial to implement over FCP, it comes free with FICON
Correct, one of my biggest regrets... but it tends to become subject
to a higher degree of automation within Linux. Some tools like mdadm
are capable of detecting all paths of multipathed SCSI device. Still,
something has to be setup within _each_ Linux that is to use
multipathing.

However, FICON has got other configuration related downsides.
If you are going to use PAV, you need to have a lot of configuration
done for that, both for the machine as well as in Linux.

> can't use HSM or other zOS based tools to manage physical volume backup
and
> restore
> Performance Analysis tools for SAN are not as mature as those for FICON
Well, working on that. We have added statistics to the FCP device driver,
which provide data as observed by Linux, in the current stage. We
are going to add more detailed measurement data. Currently, it only
comprises a plain ASCII, but flexible kernel-to-user interface - no tool
on top so far.
But I think it's still useful, and allows to build something on top.
Watch out for a Howto about FCP Troubleshooting, which will include
statistics documentation and which is to hit our developerworks page
probably this fall. I can also send you a presentation about it, if you
like
(- or the link to it when I have figured out where it has been put
by the colleagues who run the zExpo).

> FCP does less error checking than FICON, so data integrity errors are
> slightly more probable
An issue - most likely not a big one (in terms of actual problem reports)
- that is being worked on by the standardization commitees.
I would expect to see some end-to-end data checking being added to FCP
in general in the long run.

Martin Peschke
Linux on zSeries development (mainly FCP)
Boeblingen Lab





Robert J Brenneman <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[email protected]>
22/09/2005 20:00
Please respond to Robert J Brenneman


        To:     [email protected]
        cc:
        Subject:        Re: 3390 vs. FCP Connection to San running scsi



PROS:
Really really big LUN sizes ( much larger than 3390-9 or -27 )
LUNs appear as regular scsi volumes eg: /dev/sda
LUNs can reside on basically any SAN storage on the network, can use much
cheaper disk than traditional ECKD type

CONS:
Multipath is not trivial to implement over FCP, it comes free with FICON
can't use HSM or other zOS based tools to manage physical volume backup
and
restore
Performance Analysis tools for SAN are not as mature as those for FICON
FCP does less error checking than FICON, so data integrity errors are
slightly more probable

On 9/22/05, Robert Johnston <[EMAIL PROTECTED]> wrote:
>
> Good Afternoon.. I am new to this list.
> We are a medium sized VM / VSE shop planning to
> implement Linux running mainly Webshpere applications
> on our Z890.
>
> I am attempting to lay out the architecture for this
> implementation. My question is what are the pro's and
> con's of accessing scsi via an FCP connection to a San
> vs. using 3390 storage. Any help would be appreciated.
>
> Thanks in advance,
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ----------------------------------------------------------------------
> 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
>



--
Jay Brenneman

----------------------------------------------------------------------
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

Reply via email to