ADSM-L

Re: server media mount not possible

2001-10-23 17:21:59
Subject: Re: server media mount not possible
From: Mark Stapleton <stapleto AT BERBEE DOT COM>
Date: Tue, 23 Oct 2001 16:20:02 -0500
On Tue, 23 Oct 2001 09:54:19 -0500, it was written:

>Can anyone point me to a fuller description or explanation of that error
>message (in the subject)? It has no message number, and is in the client's
>dsmerror.log and a pop up window. There are no error messages in the
>server activity log, and I know that all the drives in the robot/library
>are available and that there are scratch tapes in the robot/library.
>
>Server runs TSM for AIX 4.1.0.0. Client runs TSM 4.1.2.12 (WinNT 5),
>client is trying to back up a large file (2.1 G, which is larger than
>Maximum Size Threshold of the primary backup storage pool on disk). The
>Client Options Set has Tapeprompt=yes override=no, and the client has
>tapeprompt=no. The file should go straight to the secondary backup storage
>pool, which is a tape pool, and that appears to be what the server is
>trying to do, but something is going wrong. Any ideas?

I've run across this problem before (intermittently) with TDP agents,
and may be applicable here.

It seems that when a backup is about to occur, the backup software
scans the files to be backed up and the available space on the storage
pool onto which the backup will occur. Normally, if there's more file
than space, and there is a "spill-over" storage pool designated for
the target pool, there's no problem. Occasionally, however, the backup
software doesn't "see" the spill-over pool, the server announces that
it lacks room to back up the file, and the operation stops abruptly
with a "server media mount not possible" message.

This chain of events could explain why the client error and schedule
logs reflect this message, but the server activity log doesn't.

The only workarounds I've found are: 1) designate a non-default
management class for that particular file(s) (i.e., a tape pool), or
2) set a filesize limit, beyond which files go directly to tape. Both
have their pitfalls, as well as their advantages.

--
Mark Stapleton (stapleton AT berbee DOT com)
Mark Stapleton (stapleton AT berbee DOT com)
<Prev in Thread] Current Thread [Next in Thread>