On Wednesday, 10/29/2008 at 01:41 EDT, "Romanowski, John (OFT)" <[EMAIL PROTECTED]> wrote: > One of the SFS scenario's discussed 2 LPARs sharing an SFS filepool > holding common file(s) used to setup and IPL linux guests. > > SFS would be "unreliable" if the LPAR running the SFS filepool was down > for maintenance and the other LPAR couldn't use those unavailable SFS > files to start its Linux guests.
So then let's be clear: it is the environment, *not* SFS that is unreliable. But I wouldn't let a little thing like a system outage to stop you. If you establish a CSE cluster along with the ISFC collection, you can (reliably) rig it so that the same SFS server can come up on EITHER the first or second level. (CSE would ensure that it cannot come up on both at the same time.) SFS has been around for 21 years and I think it has been very reliable. We couldn't build z/VM without it since it holds all the source code! Of course, if you're going to put mission-critical data in it, then you need to manage it. E.g. manage space and take backups. There are built-in procedures to do backups, but if you don't like them, then there are commerical backup products that will do it for you. But it's certainly true that for some folks the benefit of SFS will not outweigh the costs. Alan Altmark z/VM Development IBM Endicott
