ADSM-L

Please share v.3 HSM experiences

1998-04-14 08:47:05
Subject: Please share v.3 HSM experiences
From: Richard Sims <rbs AT BU DOT EDU>
Date: Tue, 14 Apr 1998 08:47:05 -0400
I suspect that a good number of ADSM v.3 HSM customers have by now implemented
the newly-available HSM for AIX 4.2 and beyond.  Given the year-long wait for
this incarnation of HSM, one would suspect that it has undergone a thorough
overhaul and rewrite.  As an ADSM v.2 HSM customer approaching v.3, I'm
therefore wondering if those who have tried the new HSM have found that it
resolves longstanding problems in HSM, as summarized in my attachment below?
If you've implemented the new HSM, please share your observations.

     thanks, Richard Sims, Boston University OIT

---------------------------------------------------------------------------
Standard problems in ADSM v.2 HSM:
Standard problems in ADSM v.2 HSM:

Lack of transparency:

  The HSM component of the ADSM product is supposed to provide a transparent
  means of back-storing large volumes of data, represented by stub files
  remaining in the host file system.  Throughout ADSM v.2, HSM has *not* been
  transparent, leading to usability problems which hamper introduction for
  general use in a customer site...

   - When attempting to introduce more data into an HSM file system than its
     AIX-level file system has room for, the operation fails on "File system
     full" conditions as the HSM kernel extensions in ADSM v.2 do not hold the
     operation until HSM migration can reclaim space in the host file system.
   - Attempting to retrieve data also has problems, as in an Emacs "view"
     (browse file) operation suffering a "Device not ready" condition and the
     View operation thus failing (though the attempt has triggered HSM to
     recall the file).

Chronic problems backing up HSM files:

  ADSM Backup of HSM-managed file systems has been plagued with problems all
  through version 2, mostly when the backup involves copying migrated file
  from the HSM storage pool tape to the backup storage pool tape.  In late v.2
  level 2.1.5.15, for example, doing a backup of a migrated file, where the
  backup is to go to the same tape as contains the HSM image of it, hangs on a
  "dilemma" defect: it finds the tape volume "in use" (in fact, by the backup
  that it is itself trying to do), and thinks it can't get at it, the session
  eventually timing out on "Waiting for access to input volume".
<Prev in Thread] Current Thread [Next in Thread>