We saw the same behavior when using autofs on an SGI client. A
backup of the "parent" filesystem, e.g. /machine1, would expire
all files from the portions of the filesystem managed by autofs
(e.g. /machine1/people/tlaporte, which is not a separate
filesystem, but a subdirectory that is "exported" via autofs).

I'd be curious to hear the outcome of your PMR. We ultimately had
to include VIRTUALMountpoint statements for each of the
subdirectories that was managed by autofs.

 -- Tom

On Tue, 19 May 1998, Jerry Lawson wrote:

>---------------------------- Forwarded with Changes ---------------------------
>From: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
>Date: 5/19/98 11:27AM
>To: Jerry Lawson at ASUPO
>*To: ADSM-L AT VM.MARIST DOT EDU at SMTP
>Subject: Problems with ADSM not detecting directories - Solaris 2.5.1
>-------------------------------------------------------------------------------
>John -
>
>I hope this is open as a high severity problem.
>
>I am curious as to whether level 2 thinks this is a client problem, a server
>problem, or a combination of the two.  I have had inquiries about getting the
>V3 Sun client here, but so far have not yet downloaded it.  Perhaps I'll wait
>a while longer.....
>
>Jerry Lawson
>jlawson AT thehartford DOT com
>
>
>______________________________ Forward Header 
>__________________________________
>Subject: Problems with ADSM not detecting directories - Solaris 2.5.1
>Author:  owner-adsm-l AT VM.MARIST DOT EDU at SMTP
>Date:    5/19/98 11:27 AM
>
>
>To all,
>
>I've currently got this as an open PMR with IBM Support (Level 2), but I
>thought that I would see if any other sites have run into a similar problem
>- and maybe to warn people of potential problems.
>
>A couple of weeks ago, our Sun Admins tried to bring back some of their
>files and found that all of the directories & files under the /net-3/user10
>directory had NO active backups - all versions were inactive despite the
>files still existing on the server.    I've identified at least two other
>file systems that have the same problem.    We've got one of our junior
>people poring through a 'query filespace' report and looking at file spaces
>that have minimal backup times (less than 5 secs) to see if the problems
>exist elsewhere.
>
>I went through on another affected directory /net-3/user30 and did an
>incremental backup of the sdsmjdr subdirectory via dsmc incremental
>/net-3/user30/sdsmjdr/* -su=y and all of the files were incrementally backed
>up.   I then went through and tried an incremental backup of /net-3 (dsmc
>incremental /net-3) and watched with dismay as all of the 800 backup versions
>just taken were expired!!!
>
>We're running Solaris 2.5.1 ADSM client (version 3.1.0.0) - two of the ADSM
>servers (AIX) are at 3.1.0.1 and the others are at 3.1.0.0.
>
>There are no error messages in the dsmerror.log or dsmsched.log.   The only
>indication that you get is if you happened to look at the dsmsched.log on
>the night that all of these files went inactive - you would see an abnormal
>number of files expired, but unless you happened to notice the backup times
>for the file spaces decreasing down to next-to-nothing, you probably won't
>catch that until it's been deleted out of your dsmsched.log.
>
>We've tried to minimize our losses by setting the RETONLY parameter on the
>STANDARD copy group to 365 days (it had been 90) to allow sometime for the
>cause to be identified and a solution devised.
>
>Has anyone else backing up Solaris 2.5.1 boxes experienced a similar
>problem???
>John Rushton
>Lockheed Martin M&DS
>