Conference smurf::ase

This can be done.  The main thing is not to NFS mount it at the ASE 
mount point.  Another thing is not to try and mount it durring bootup 
before ASE has started.

re: .0
    
    It can be done - but you should make sure that you understand
    what is going on thoroughly... this notes conference is full
    of people's problems when they (we) did not completely understand
    all that ASE is doing under the covers.
    
    Be particularly aware that 
    
    - ASE is going to call the shutdown script during the ASE startup
    process on each node where the service is NOT going to be started
    at that time.
    
    - ASE will [Blocate the exported directories in
    /var/ase/mnt/servicename/directorypath but a mount of
    'directorypath@servicename' will actually find the desired
    directories.

    - there is no clear, supported mechanism for coordinating the
    order of startup of services
    
    - the shutdown of a service will be impeded (to put it delicately)
    if any of the files are open locally on the system providing
    the service.
    
    Good luck.
    
    

    Hi,
    
>    In an ASE cluster of two members, is it recommended that an ASE member
>    to NFS mount the NFS service which is currently running on the other member system ?
                      +++++++++++
    
    Yes, if it is a NFS service without any problem. You can even place the
    servicename:/exported_path (or /exported_path@servicename) in the
    /etc/fstab file. I suggest that you place the NFS option "bg" to put
    the mount in "background" just in case the service is not running at
    the boot-up of this system. You even don't need any particular stop
    script action as an open file on a NFS filesystem does NOT block the
    un-mounting operation.
    
    If it is NOT an NFS service but a DISK service, then the things are
    more complicated. You should NOT use directly /etc/exports to export
    the DISK service filesystem(s), but use the ASE provided scripts in
    /var/ase/sbin (nfs_mountd and nfs_lock). There is a note explaining how
    to proceed in this notefile
    
    Manu.

    
.    Yes, if it is a NFS service without any problem. You can even place the
.    servicename:/exported_path (or /exported_path@servicename) in the
.    /etc/fstab file. I suggest that you place the NFS option "bg" to put
.    the mount in "background" just in case the service is not running at
.    the boot-up of this system. You even don't need any particular stop
.    script action as an open file on a NFS filesystem does NOT block the
.    un-mounting operation.
.
    
    Manu is, as usual, correct. Of course, you need to remember
    that you should not locally mount that directory on the system
    where it 'usually' resides - only nfs mount it.
    
    Also, don't forget to set the syconfigtab parameter for loop
    back mounts...    

    And the sysconfigtab entry for loop back is???
    
    

    re .5
    
    vm:
            ubc-nfsloopback = 1

    How come I don't find this parameter in my sysconfigtab files?
    
    V1.4 TCR
    V4.0b UNIX
    
    -Tony

    re .7
    Well, the /etc/sysconfigtab file usually contains only a fraction of
    the kernel parameters. The rule of thumb is: you only put parameters
    there that you want to assign values different from the default values
    hardcoded into the kernel.
    
    	sysconfig -s 
    
    will tell you which subsystems are currently configured into the
    kernel. And
    
    	sysconfig -q <subsystem>
    
    will tell you the current values of all parameters for that subsystem.
    So try
    
    	sysconfig -q vm | grep nfs
    
    to check your current setting of ubc-nfsloopback. In any case I always
    only trust sysconfig -q because /etc/sysconfigtab might have changed
    since the last re-boot. Or a parameter setting might not have been
    accepted during re-boot.
    
    	Martin
    

Re:.4 - Dave Ascher
>    Also, don't forget to set the syconfigtab parameter for loop
>    back mounts...    
Is this really necessary?  Reading this note, I remembered I forgot to do this, 
yet my NFS service with loop back mount works fine.  

Why? Could it be that this parameter does not need to be there because the mount 
goes against the IP name/address for the NFS service rather than to the hostname
of the system doing the NFS mount? Or am I getting penalties in performance that 
I just haven't noticed yet?

I guess the real question is, how does this ubc-nfsloopback parameter actually
work?

Herta

    re: .8
    
    I used both "sysconfig -q vm | grep nfs" as well as "dxkerneltuner"
    and found that all 14 of my systems that I have configured with ASE
    in various configurations, do NOT have this parameter setting!
    
    As .9 brings up, am I running with performance problems I don't know 
    about?
    
    -TB

    re .10
    Are you sure you are running 4.0b?
    
    Check out TURRIS::DIGITAL_UNIX
    
    	8338.*
    	9345.*
    
    	Martin

    Yes V4.0b on all of the 14 systems....

    Sorry to cause such a panic... It is my understanding that
    the parameter takes care of a problem that has existed since
    3.2A or so - our first SMP version of UNIX. The symptom was
    that processes that were using files that are nfs mounted from
    directories that are exported from the same system as the client
    is running on will get themselves into "U" state - which means
    that they cannot be stopped and that they will never continue.
    SOme kind of underlying corruption of ubc structures. There
    was a series of apparent mildly effective patches that came
    out under 3.2x which probably still left some design holes 
    and made the problem less likely to occur (and harder to identify
    when it did occur). 
    
    Personally, I avoid the use of nfs loopback mounts rather than
    have to worry about this old bug cropping up again. I'm not
    all that confident about what appears to be yet another crude
    workaround that gets turned on by this parameter.
    
    When faced with the necessity of having an nfs service that
    moves between nodes and that has to be mounted on both nodes
    I use a disk service with links on the local system to the
    directory in question... which leads to a lot of pain in the
    neck complexity like having to NOT have ASE do the file system
    mounts/umounts so I can have the start/stop scripts do the
    right things at the right times... like use lsof or fuser to
    identify any processes that have locally opened files in the
    file system so they can be killed (which may be a problem for
    some applications, I would think), remove links and create
    links, etc.. .
    
    Unfortunately I do not have any simple example scripts to share
    - the functionality is buried in complicated scripts used with
    SAP. 
    
    

    So can someone explain to me whether or not this parameter should be 
    set at "1" or left at "0" and what the implications are?
    If it should be set, why isn't the INSTALL doing it or the
    documentation telling me to do it?
    
    I'm telling folks that for reasons of performance they should not be
    using NFS mounted filesystems.  If I'm getting no performance benefit
    from ASE NFS loopback then I want to tell them instead of having them
    tell me.
    
    	-TB

Hi

 Set it to 1, it fixes a possible deadlock condition within the buffer
cache code when the system is a client/server of itself.

I think we need to improve the docs here if no one can find
references to it in release notes/tuning guides...

A qar might be in order here.

Thanks for all the suggestions.
We tried the scenario with the following configuration:

- Define the NFS service.

- the service is NFS exported as, say /service_mount@service_alias

- Each member system acts as a NFS client to mount the NFS service.
  The member running the service will be doing a NFS loopback mount
  on the NFS service. We have done the vm: ubc-nfsloopback=1

- Add the nfs entry in  /etc/fstab on the two member systems

  /service_mount@service_alias    /nfs_mount  nfs  hard,rw,intr,bg 0 0



But when we try to manually relocate the NFS service from
member A to member B using asemgr, it fails to do so.

Can I really manually relocate the NFS service using asemgr,
under such scenario? Or somethings I have been missing?

-feynman

[Posted by WWW Notes gateway]

    Is anyone on the system exporting the service accessing the files
    directly (rather than the NFS mount)?
    
    What does the daemon log have to say?
    
    Jc
    

Because this configuration is not documentated in the
manuals, the customer need to know whether Digital
will support the configuration or not in case
there are further issues encountered in the future.

Could someone comment on this?

-feynman

[Posted by WWW Notes gateway]

    
    ...
    
    if everything were documented in the manuals, I would not find the
    time to read them :-)  Go ahead, I will support you !
    
    Manu.