[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference cookie::smfs

Title:Sequential Media Filesystem for OpenVMS VAX
Moderator:COOKIE::KYLER
Created:Mon Aug 30 1993
Last Modified:Thu May 01 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:66
Total number of notes:198

61.0. "smfs-e-loaderr - sls-e-volonothdrv on second copy series" by CSC32::V_HEINICKE () Mon Feb 10 1997 13:56

    A customer is running V1.2 of SMFS and V2.8 of MDMS - he is
    currently in the process of upgrading to V2.8A as we speak.
    
    He has a Tl822.  When he does a copy command to the MX device,
    a tape is loaded and the copy proceeds to do the write.  After the
    write has completed, the tape remains in the drive and the tape
    drive is allocated to the SLS process.  The next time a copy is
    requested, the following errors are returned:
    
      smfs-i-log_error, unexpected error on file system mxa0
      smfs-i-routine name, in routine load - media checkpoint 3
      smfs-e-loaderr, error loading volume nnn on drive nnn
      sls-e-volonothdrv,  specified volume already loaded in another drive
    
    It is as if SMFS is not completing the process by telling SLS to unload
    the tape in the drive.  Therefore, the volume is left in the drive and
    when the next command is issued, it cannot act on the copy as the
    volume is in a different drive tahn what SMFS is expecting.  I suspect 
    that this will probably need to be elevated but I wanted to see if there 
    were a step missing from the customer's perspective before I submitted 
    the elevation.  Also,  I wanted the customer to be running the latest 
    version of MDMS as there were some robotic type fixes in V2.8a.  He will 
    be calling me back to tell me if the error message have changed.
    
    Any suggestions or recommendations before I elevate.
    
    Thanks,
    
    Victoria Heinicke
T.RTitleUserPersonal
Name
DateLines
61.1COOKIE::KYLERTue Feb 11 1997 13:3616
    SMF deliberately leaves the cartridge loaded as an optimization,
    assuming that it is likely that the tape will be needed again soon.  If
    another tape is needed in the drive, the load will automatically
    generate an unload.
    
    The problem here is the allocation of the drive, apparently.  MDMS will
    select the drive that the cartridge is already loaded in if it is
    available.  But if another process has the drive allocated, it will
    select another drive, resulting in the VOLONOTHDRV error. 
    
    What process is the drive allocated to?
    
    Is the customer using ALLDEV?
    
    - Dan.
    
61.2CSC32::V_HEINICKEWed Feb 12 1997 11:4220
    Hi Dan,
    
    The customer is using ADLLDEV and SELDEV and the process that has
    allocated the drives is the SLS process.  His intent is to make these
    drives available only to the SMFS process so that no other user can
    access the drives.  Explained to him that historically we have strongly
    recommended alldev and seldev not be used - always caused major
    problems.  He will remove the drive designation and restart SLS to
    verify that his original problem is resolved.  But he does want a
    workaround so that he can dedicate the drives specifically to the SMFS
    process so that ONLY that process has access to the drives?  Can
    this be done?                          
    
    Also he want to make the MX virtual device seen clusterwide.  How can
    he do so.  The physical drive is seen via TMSCP but the virtual MX
    device is not seen.  Again any recommendations?
    
    Thanks,
    
    Victoria
61.3CSC32::V_HEINICKEWed Feb 12 1997 13:2818
    Dan,
    
    One additional question added on to note 61.2.
    
    Although we do not recommend using ALLDEV and SELDEV, we SHOULD be
    able to do so.  Since ALLDV was set up initially, the drives initially
    were allocated to SLS.  It appears that when the copy was requested,
    the drive was already allocated to SLS, and SLS did find a free volume
    and mounted it.  According to the customer, the acp process took
    ownership of the drive at that point.  Once the copy was completed, it
    returned ownership of the drive to the SLS process.  Is this correct?
    If so, why cannot SMFS determine that the sls process has the tape loaded
    in one of the drives dedicated to the sls process instead of trying
    to find it in one of the other dedicated drives?
    
    Thanks,
    
    Victoria