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.
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
|
