One problem w/ SFS is that we don't run it on our second LPAR at all.
Anything that we want to be able to run on both systems has to reside on a
minidisk. SFS isn't a choice.

If IBM would allow the vmsys: pool to be shared between systems, we'd be
more likely to use it.

-- 
Robert P. Nix          Mayo Foundation        .~.
RO-OE-5-55             200 First Street SW    /V\
507-284-0844           Rochester, MN 55905   /( )\
-----                                        ^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."




On 10/28/08 2:13 PM, "Tom Duerbusch" <[EMAIL PROTECTED]> wrote:

> True about another point of failure.
> 
> However, how many times a year is your SFS server(s) down?
> I find an occasional crash (usually due to me) about once every year or two.
> It's really a pain, as my CMS type servers, don't auto reconnect.  So I have
> to manually force off the servers and let the be brought up by AUDITOR.
> (easiest way to do this)
> 
> But, for a guest, such as Linux, when you (x)autolog them, they connect to
> SFS, access the PROFILE EXEC and disconnect (via IPL) in a matter of a second
> or two.
> 
> However, your point, is good, especially in a near 24X7 Linux shop.  A shared
> 191 minidisk is better.  Until you have two users, access the shared disk in
> R/W mode, to update it.  No protection.  SFS will always protect you.  Manual
> procedures can minimized the R/W problem, but can't eliminate it.  Just like
> SFS problems can be minimized but not eliminated.
> 
> But thinking of this...
> There is one SFS combination of problems, which would be a major concern.
> Backing up SFS via the VM supplied utilities and the backup (or VM) crashes.
> SFS will come up, but that storage pool is locked.  It is easy to unlock it,
> when you know to do that.
> During this time, if a guest tries to access their SFS directory that is on a
> SFS pool that is locked (would be a much more frequent occurrence if there was
> a VM crash), it could lead to a lot of heart burn.
> 
> A 191 minidisk can be much better.  And of course, not to IPL CMS, but to IPL
> 190, just in case the CMS saved segment is lost <G>.
> 
> Tom Duerbusch
> THD Consulting
> 
>>>> Scott Rohling <[EMAIL PROTECTED]> 10/28/2008 1:56 PM >>>
> Just curious why you think SFS is better than a 1 cylinder shared minidisk?
> To me - it's a point of failure as an SFS pool server must be running just
> to get to the PROFILE EXEC...
> 
> Scott Rohling
> 
> On Tue, Oct 28, 2008 at 11:32 AM, Tom Duerbusch
> <[EMAIL PROTECTED]>wrote:
> 
>> 1.  As has been said, you don't need a R/W disk to IPL.  R/O is good.  SFS
>> directory is even better.
>> 2.  Once you IPL Linux, you are not in CMS anymore.  You won't be doing
>> anything with your a-disk anymore.  So make it easy on your self, when you
>> need to make changes to the profile exec.  Put it in a SFS directory.
>> 
>> Tom Duerbusch
>> THD Consulting
>> 
>> 
>> 

Reply via email to