ADSM-L

[no subject]

2015-10-04 17:31:35
Reinhard,

Even using the dsmmode -t=p option when doing a selective backup, changes the atime of the file.
I've just tested it.  Using "istat filename", one can see the access time for that file.  The dsmmode -t=p option does not preserve the access time as they claim.  So this is a huge problem for me.  We can only migrate files on our /R3_data filesystem if the files have not been accessed for at least 30 days.  Any other ideas as on how to solve this problem?

Regards
Gerrit
 

Reinhard Mersch wrote:

Gerrit van Zyl writes:
 > Reinhard,
 >
 > I had a look:
 >
 > 1.  No errors in the AIX errorlog.
 > 2.  No, I do not catch HSM error messages with the ERRORPROG option.  How do you use this?

What I am doing is: In dsm.sys:
   ERRORPROG          /var/adsm/errorprog
/var/adsm/errorprog is a shell script essentially containing one line:
   mail -s "Mail from HSM" backup
This sends the HSM error message to "backup" (which is me). Don't forget
to make that script executable.

 > 3.  Dsmmonitord is running.
 > 4.  This is a huge filesystem, and no, it is impossible that all of the files have been accessed.

You are backing them up, don't you? (See below.)

 > 5.  Dsmreconcile gives the following:
 > f03n13sw / # dsmreconcile -c /R3_data
 > ADSTAR Distributed Storage Manager
 > space management Interface - Version 3, Release 1, Level 0.7
 > (C) Copyright IBM Corporation, 1990, 1999. All Rights Reserved.
 >
 >
 > Reconciling '/R3_data' file system:
 >   Querying the ADSM server for a list of backed up files...
 >          Received 705752 entries

Boy, this IS huge. There seem to be a lot of small files within the
filesystem. Don't forget that small files (4KB or less) will not be
migrated! Does this explain your problem?

 >   Now traversing the file system...
 >   Writing the new migration candidates list...
 >          Note: unable to find any candidates in the file system.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Obviously, this is the problem. I can only guess about the reason. All
possible candidates smaller than 4KB? To repeat myself: I would set
AUTOMIGNOUSE to 0. APAR IX89650 might apply to you (text appended below).

 > ANS9250I File system '/R3_data' reconciliation completed.
 >
 > 6.  I am able to manually migrate files.
 > 7.  Set the quota (e.g. "dsmmigfs update /R3_data -Quota=1024G"
 >      you do allow 1 TB from this filesystem to be migrated, don't you?)
 >      What do you mean with this?

The quota specifies the amount of data that may be migrated. You did not
specify a quota, I would definitely do so. (The default is quite small.)

APAR IX89650:

APAR NUMBER: IX89650           RESOLVED AS: DOCUMENTATION ERROR

 ABSTRACT:
 IX89650: UNABLE TO SPACE MANAGE FILES BASED ON AUTOMIGNONUSE=1 AS ADSM
 INCREMENTAL AND SELECTIVE BACKUPS ALTER THE FILES ATIME VALUE.

 ORIGINATING DETAILS:
 The ADSM backup/archive client alters files atime value during
 selective or incremental backups.  This results in HSM being
 unable to properly migrate files based on the automignonuse
 value set in the mgmtclass. This was tested on AIX 4.2.1 with
 the 3.1.0.6 client code.

 LOCAL FIX AS REPORTED BY ORIGINATOR:
 Run the selective or incremental backup as a command parameter
 of the dsmmode -t=p command. Example:
 'dsmmode -t=p dsmc i'

 RESPONDER SUMMARY:
 The BA client in ADSM v2 preserved the atime
 of files for backup and restore. Preserving the atime
 of files for reading has been disabled 11/97. Reason:
 when preserving the atime (using syscall utime(), the ctime
 of the file was indirectly updated. HSM uses ctime as part of
 the key for the premigration database. The ba client uses the
 ctime (besides other file attributes) to compare the state
 of files. Unfortunately, this modification has never been
 reflected in the documentation,  since it limits the use of the
 'non-usage' option of the ADSM HSM client.

 RESPONDER CONCLUSION:
 Trying to preserve the time stamp of a file,
 using syscall utime(), indirectly changes the ctime time stamp,
 which leads to undesired side affects.

--
Reinhard Mersch                        Westfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany      Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de                       Fax: +49(251)83-31653

--------------2CB9F20D48B7370DE82C071F-- --------------4AB1034EE9ED81EFB01CB71F
<Prev in Thread] Current Thread [Next in Thread>
  • [no subject], Unknown <=