First, did you stop/restart the scheduler on the TSM Clients after the
downtime and after each configuration change? If not, try that before
reading on. My understanding (consistent with past reading and
experience) is that 'dsmc' won't pick up changes unless/until it's
restarted, and won't necessarily stop/restart itself after a broken tcp/ip
session. If the scheduler cannot connect to the TSM Server during the
backup schedule window, or is restarted after the close of the schedule
window, it will just reschedule itself for the next backup window. Dig
into the tSM Clients' 'dsmsched.log' and 'dsmerror.log' files for more
info on what's going on.
We occasionally experience TSM Client hangs on stale NFS handles on
Solaris, Digital and SGI clients. By policy, we don't back up any NFS
filesystems, just local. Nevertheless, during the initial client/server
exchange of data, the client has to walk the OS filesystem just like 'du'
and 'ls -R' and when it encounters a stale NFS mount will just hang there
like they do. This is an OS problem; I don't think TSM can be configured
to completely avoid it. We think that two prior recommendations from
ADSM-L (setting NFSTIMEOUT=120 and renaming/disabling 'dsmstat') helped in
some cases, but the mountpoint containing the stale NFS handle was still
skipped.
Since mountpoints are usually at the top level of the filesystem, directly
under root '/', and since root '/' is always the first filesystem mounted,
it's virtually guaranteed that with a default configuration - no domain
statements; using 'dsmc sched' only; no client-initiated 'dsmc incr <f/s>'
processes - the client will hang on the first filespace '/', and all
including '/' will miss.
When it occurs, we can mitigate the problem: a) by running individual
'dsmc incr <f/s>' commands on the client for the other unaffected
filespaces; or b) by adding domain statements in the reverse order of that
reported by 'dsmc query opt' ('dsmc show opt', depending on your *SM
release); or c) by adding 'exclude.fs /' to your inclexcl file. This
still either hangs on or skips '/', so it does not get backed up - but
everything else usually completes.
Our Unix sys admins have had to reboot Unix TSM Clients to clear stale NFS
handles and restore our ability to backup '/' or whatever mountpoint
contains the stale NFS handle. You need to identify and eliminate the
root cause of repeated stale NFS handles, which could just be a user's bad
habit of exporting and then remotely-mounting a cd from a different
server, then removing the cd from the drive before unmounting/unexporting
it.
-my $.02
Kent Monthei
GlaxoSmithKline
"Adams, Mark" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
15-Mar-2002 13:48
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: ADSM-L
cc:
Subject: Re: NFS MOUNTS
All of the TSM code is on a local filesystem.
Just TSM client activity hangs.
Of course df will hang as well.
-----Original Message-----
From: David Longo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 11:59 AM
To: [EMAIL PROTECTED]
Subject: Re: NFS MOUNTS
Does the NFS server in Denver provide any filesystems that say have
TSM code on them or anything like that? Does everything else on
the client(s) in Omaha work fine except TSM? Do you have anything
else other than standard AIX jfs filesystems - any AFS/DFS or
anything else?
David Longo
>>> [EMAIL PROTECTED] 03/14/02 11:47AM >>>
We have a server in Denver that is serving 2 filesystems in Omaha.
The server in Denver was down for 10 hours for maint.
When clients in Omaha were trying to access TSM in any fashion the client
would just hang and do nothing, eventually fail all together.
I have run some tests since then. Changing DOMAIN statements,
include/exclude statements, etc. nothing seems to work.
Mark
-----Original Message-----
From: David Longo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 9:35 AM
To: [EMAIL PROTECTED]
Subject: Re: NFS MOUNTS
Did you check the dsm.opt file for a DOMAIN statement? Are you
somehow specifically including the NFS Mounts in the backup.
There may be some other problem.
You say if the NFS server is down. What is it serving? Tell us a bit
more
about your setup.
David Longo
>>> [EMAIL PROTECTED] 03/14/02 09:56AM >>>
We are running AIX 4.3.3 ML09
I have tried the nfstimeout parameter but our backups still fail.
The client just stales out, if the NFS server is down.
Mark
-----Original Message-----
From: Gabriel Wiley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 13, 2002 8:27 PM
To: [EMAIL PROTECTED]
Subject: Re: NFS MOUNTS
What OS ??
This taken from admin guide for AIX pg 221:
Nfstimeout
The nfstimeout option specifies the number of seconds the server
waits for a status system call on an NFS file system before it times out.
You can use this option to mitigate the default behavior of status
calls on NFS file systems. For example, if an NFS file system is
stale, a status system call will be timed out by NFS (softmounted) or
hang the process (hardmounted).
When the value of this option is changed to a value other than zero,
a new (child) process is created to issue the status system call. The
new process is timed out by the main (parent) process and the
operation can continue.
Note: The server can also define this option.
Options File
Place this option in the client system options file (dsm.sys) within a
server stanza or the client options file (dsm.opt).
Syntax
NFSTIMEout number Õ
Parameters
number
Specifies the number of seconds the server waits for a status
system call on an NFS file system before timing out. The default
is 0 seconds.
Examples
Options file:
nfstimeout 10
Command line:
-nfstimeout=10
Good luck~
Gabriel C. Wiley
ADSM/TSM Administrator
AIX Support
Phone 1-614-308-6709
Pager 1-877-489-2867
Fax 1-614-308-6637
Cell 1-740-972-6441
Siempre Hay Esperanza
David Longo
<David.Longo@HEALTH To:
[EMAIL PROTECTED]
-FIRST.ORG> cc:
Sent by: "ADSM: Subject: Re: NFS MOUNTS
Dist Stor Manager"
<[EMAIL PROTECTED]
DU>
03/13/2002 05:26 PM
Please respond to
"ADSM: Dist Stor
Manager"
TSM by default DOES NOT backup NFS mounts. You have to specifically
tell it to with the DOMAIN statement in dsm.opt or dsm.sys, depending
on your platform. What platform is this?
Maybe there is a CLOPSET set on the server to back it up?
David Longo
>>> [EMAIL PROTECTED] 03/13/02 04:43PM >>>
We ran into a problem with NFS mounts on one our clients.
The NFS server went down and when the client tried to backup it just hung.
My question is why does TSM back up NFS by default with no real way to
turn
it off.
What can we do to not look at the NFS mounts.
I have tried different exclude statements, but to no avail.
Does anyone have any suggestions?
TSM server 3.7.4
Client 3.7.2.15
Mark Adams
Systems Programmer
CSG Systems, Inc.
"MMS <health-first.org>" made the following
annotations on 03/13/02 17:39:49
----------------------------------------------------------------------------
--
This message is for the named person's use only. It may contain
confidential, proprietary, or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it, and notify
the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. Health First reserves the right to monitor all e-mail
communications through its networks. Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of a particular
entity; and (2) the sender is authorized by the entity to give such views
or opinions.
============================================================================
==
"MMS <health-first.org>" made the following
annotations on 03/14/02 10:47:54
----------------------------------------------------------------------------
--
This message is for the named person's use only. It may contain
confidential, proprietary, or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it, and notify
the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Health First reserves the right to monitor all e-mail
communications through its networks. Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where
the
message states such views or opinions are on behalf of a particular
entity;
and (2) the sender is authorized by the entity to give such views or
opinions.
============================================================================
==
"MMS <health-first.org>" made the following
annotations on 03/14/02 13:12:47
----------------------------------------------------------------------------
--
This message is for the named person's use only. It may contain
confidential, proprietary, or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it, and notify
the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Health First reserves the right to monitor all e-mail
communications through its networks. Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where
the
message states such views or opinions are on behalf of a particular
entity;
and (2) the sender is authorized by the entity to give such views or
opinions.
============================================================================
==
