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

Conference cookie::hsm

Title:File Shelving
Moderator:COOKIE::HOLSINGER
Created:Mon Mar 15 1993
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:346
Total number of notes:1204

340.0. "Cache directory performance on large (4.3 Gb) disks" by UTRTSC::BOOR () Wed May 21 1997 07:49

Hello,

customer replaced his optical jukebox with 4.3 Gb disks.
These drives are partitioned into smaller pieces with the VDdriver and/or
LDdriver, giving you smaller virtual disks (with the size of the optical
platters).
Customers has done this because of directory performance issues with OpenVMS
(the original opticals contained lots of small (10 block) files, giving you
 large directories.
 Combining these cached directories into 2 large disk would imply a very
 large [HSM_CACHE] directory, giving real perfomance problems, because the
 HSM_CACHE.dir file will be (much) bigger than 128 blocks.
 Testing in customer's environment showed a 5000 blocks(!) HSM_CACHE.dir
 file)

Trying to setup these (virtual) disks as cache devices will (correctly)
return a 'SHP_INVALID_CACHE' error messages.

Is there any reason behind caching devices being 'real' disks ?
[For OpenVMS point-of-view these are disks and can be mounted system(cluster)
 wide].

Is a (hardcoded) check made on device name and/or type ?

This restriction isn't mentioned in the SPD ..
	(or did I miss something)


regards,
	Rob Boor, Off-Site Services, Utrecht - The Netherlands.
T.RTitleUserPersonal
Name
DateLines
340.1only a small restrictionCOOKIE::HOLSINGERHSM Engineering, DTN 522-2843Wed May 21 1997 20:0116
Hello Rob,

I presume that the 'SHP_INVALID_CACHE' error message you refer to is an 
SHP exception, in the SHP_ERROR.LOG file, as I could not find any references 
to this string in our message files. 


Your customer should not have a problem configuring these virtual disks, as 
as each shows up as a disk-class device in lib$getdvi.

The only reason I can see that the code will fail a set cache... would be when 
the node is in a cluster but the cache device under configuration is local. 
Is this the case?

Regards,
/Paul
340.2UTRTSC::BOORThu May 22 1997 10:047
Paul,

yes I think the VDdriver creates local disks.

Will ask customer to use the LDdriver, which can MSCP serve the virtual disk.

Rob.
340.3Variants existEVMS::EVERHARTThu May 22 1997 13:5113
    Either driver (vddriver or lddriver) can create mscp serveable
    disks. With vddriver you need to create the contiguous container
    files yourself separately. (copy/contig/alloc followed by
    set file /end and set file /nomove, or use sysgen/crea).
    
    I have a differently named free driver that will create virtual
    disks on files that don't need to be contiguous. It can optionally
    have these files accessed via decnet, or encrypted, or
    compressed, or in process virtual memory (with various flavors
    of logging/journalling) or a few more. There are also a few
    other variant drivers that do stuff like shadowing or striping
    or WORM handling...
    
340.4Init order?EVMS::EVERHARTThu May 22 1997 13:5813
    Could there be an initialization order problem somehow? If the vddriver
    being used is of any recent vintage, there should be no way HSM
    or anything else would know they are not just J Random local disks,
    so long as the device units are connected with sysgen or sysman io
    and are assigned to containers with asnvd before they are needed.
    
    If however HSM is getting started before the VD units are set up,
    its initialization may either fail to find the VD devices, or see
    them as offline. I would imagine much the same could happen with
    LDdriver.
    
    <5000 block cache dir! Holy hannah!>
    
340.5Make server node to CATALOG SERVERATZIS3::KARTNER_MHOUSTON, we have a problemFri May 23 1997 06:2011
    Hi!
    
    If the drives are only local on one node you could assign this one
    to be the catalog server of you cluster. This should fix the problem
    with the local cache disks. Are the devices connected to one
    of your servers (reliable & fast)?
    Remember that only this node will do catalog uptdates and cacheserving
    after enabling this feature
    
    								bye
    								Michael
340.6Works nowUTRTSC::BOORFri May 30 1997 04:338
Finally got it working.

The problem was with the virtual disk drives NOT being 'available to cluster'. Even if this node is catalog-server
these disk MUST be 'available to cluster'.

$ld connect/SHARE disk_file LDAnn did the trick.

	Rob.