On 25/03/2020 14:15, Skylar Thompson wrote:
We execute mmbackup via a regular TSM client schedule with an incremental
action, with a virtualmountpoint set to an empty, local "canary" directory.
mmbackup runs as a preschedule command, and the client -domain parameter is
set only to backup the canary directory. dsmc will backup the canary
directory as a filespace only if mmbackup succeeds (exits with 0). We can
then monitor the canary and infer the status of the associated GPFS
filespace or fileset.
I prefer this approach I think than grovelling around in log files that
could easily break on an update. Though there is a better approach which
in my view IBM should be using already in mmbackup.
It came to me this afternoon that one could use the TSM API for this.
After a bit of Googling I find there is an API call dsmUpdateFS, which
allows you to update the filespace information on the TSM server.
Fields that you can update include
DSM_FSUPD_OCCUPANCY
DSM_FSUPD_CAPACITY
DSM_FSUPD_BACKSTARTDATE
DSM_FSUPD_BACKCOMPLETEDATE
Information on the API call here
https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/api/r_cmd_dsmupdatefs.html
How do we submit this as a feature request again? That said in my view
it's a bug in mmbackup. The latest in a very long line stretching back
well over a decade that make mmbackup less than production ready rather
than a feature request :-)
I feel a breakout of a text editor and some C code coming on in the
meantime.
JAB.
--
Jonathan A. Buzzard Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
