Conference smurf::ase

2021.0. "DEC7000 asemgr confused by rzb2 and rzb20" by EVTAI1::BROCHARD (Manuel Brochard - French CSC) Thu Apr 24 1997 12:45

       Hi,
    
        One of mine collegue try to configure 2 services on a ASE v1.3A +
        official patch on a DEC7000 configuration, running OSF v3.2G
    
        The first service was a Disk service (above AdvFs) named pac001 which
        was build on 1 LSM diskgroup "sapdg" composed of 68 disks (HSZ40).
        There was no problem during service creation and relocation was OK.
    
        After that, he tries to setup a second Disk service, named pac004, which
        was build above AdvFs too, on a different LSM diskgroup "apsdg".
        This domain was composed from 2 logical units rzb2 and rzc2.
            When all questions were asked by asemgr, it failed to create the
        service with the following message :
    
        "*** Found disk /dev/rzb20 on more than one service (pac001 and pac004)"
    
        The /dev/rzb20 has absolutely nothing to do with this service, yes it
        belongs to the previous service pac001, but in the last service (pac004)
        there's only /dev/rzb2 and /dev/rzc2.
    
        voldg list confirm this,
    
        only rootdg and apsdg were online, apsdg was only rzb2 and rzc2.
    	sapdg was offline and available on the second ase member.
    
        It was the first time that asemgr was run, rzb2 never belongs to an
    	old ase service.
    
            With the DEC 7000, there's a HSZ bus with ID 0, so devices becomes
            rzb2, rzc2...
            does it can confuse asemgr with the synthax of /dev/rzb20 ?
    
           I think that using bus 0 is supported on DEC 7000.
    
        Does asemgr in debug mode can help ?
        Is it possible to get the source code of asemgr to look at which test is
        performed to check the devices ?
    
            Many thanks for advices / info.
    
        Manuel.
    
    
                                                                 

    Hi Manuel,
    
    I already have encountered that problem when I removed a volume from
    one diskgroup and move its disk to another diskgroup. You should avoid
    placinfg the physical disk offline.
    
    A trick to check that the disk is really member of the other service is
    to do the following:
    
    # strings /var/ase/config/asecdb > /tmp/ase-config
    # vi /tmp/ase-config
    
    And search with vi for the disk rzb2 and you will see in each sequence
    it is and for which service.
    
    Doing a simple asemgr -dv service_name will not show you when a
    physical disk is still attached to a service.
    
    Manu.

    Manuel,
    
    I took a quick look at the ASE V1.3 code.  It does appear that there
    is a bug in it which would lead to the error that you found (again,
    this was only a quick check).  This code has been completely changed
    for TCR V1.4 and this bug (again) looks to be gone.  You may want to
    file a QAR against V1.3 so you can get a patch for the problem.
    
    If you upgrade to V1.4 my guess is that you will not seen this same
    problem.
    
    -- Greg

    
    Thanks for having a look at my note.
    
    	 I talk with the customer and he thinks he will use another disk
    to avoid problem, before he will upgrade.	
    
    Thx,
    
    	Manuel.