ADSM-L

Re: problem with solaris 2.6

1998-06-19 20:32:42
Subject: Re: problem with solaris 2.6
From: Jennifer Davis <jedavis AT DFW DOT NET>
Date: Fri, 19 Jun 1998 19:32:42 -0500
I've checked this support. ADSM does not officially support Loopback
filesystems.
However, I have been told that there is already a Design Change Request on
file
to add this support.

FYI!

At 12:03 PM 6/19/98 +0100, you wrote:
>
>Eckhard,
>
>I think this is all part of the same problem that Gavin posted to adsm-l
>yesterday (see below) :  at Solaris 2.6, user filesystems are automatically
>made as "loopback" filesystems (and this is also an option at Solaris 2.5
>and 2.5.1).  The ADSM version 3 client is not handling these filesystems in
>what I consider to be a sensible manner.
>
>I have done some fairly extensive tests with the V3 and V2 client on Solaris
>(version is irrelevant) with the behaviour/handling of loopback filesystems.
>
>At V2 :  without a Domain statement and an implicit all-local, adsm incr
>backs up /export/home/things and ignores /home/things.  I believe this is
>reasonable.
>
>At V3 :  ( and you need to get the latest fixtest version - see Gavin's
>message), with the same scenario :  ADSM backs up the whole thing twice,
>both as /export/home/thing and as /home/thing.
>
>I believe this behaviour is unacceptable and in my PMR it has been suggested
>that ADSM is working as designed and I should submit a design change request.
>
>I think the design is broken and should be fixed to behave as the V2 client
>did.
>
>In addition, I think the expiration behaviour you are seeing is a bug in the
>generally available 3.1.03 code which you may be using; the best available
>is the IP21297T2 (for sol26) fixtest version - which is in the
>adsm/fixtest/v3r1/sol/sol26 directory on index.stosys.ibm.com.
>
>Hope this helps, Sheelagh
>---------------------------------------------------------------------------
---
>Sheelagh Treweek                         Email:
>Sheelagh Treweek                         Email:
sheelagh.treweek AT oucs.ox.ac DOT uk
>Oxford University Computing Services     Tel:   +44 (0)1865 273205
>13 Banbury Road, Oxford, OX2 6NN, UK     Fax:   +44 (0)1865 273275
>---------------------------------------------------------------------------
---
>
>
>
>===========================================================================
====
>
>>From owner-adsm-l AT VM.MARIST DOT EDU  Thu Jun 18 06:07:25 1998
>MIME-version: 1.0
>X-Lotus-FromDomain: ALCATELAUSTRALIA
>Date: Thu, 18 Jun 1998 14:40:10 +1000
>From: Gavin Ring <Gavin.Ring AT ALCATEL.COM DOT AU>
>Subject: ADSM backing up the same data twice
>To: ADSM-L AT VM.MARIST DOT EDU
>
>There was a thread a while back where the Solaris ADSM v3 client was
>skipping directories during incremental backups.
>
>The problem is described in APAR IC20712 and APAR IC20907. A new version of
>the client code  was made available for download from the IBM
>FTP server.
>
>I have installed the new code and it does fix the problem of ADSM skipping
>directories, however I have found a significant change in the way the V3
>client works compared with the way the V2 client works.
>
>In summary the ADSM v3 client can backup the same data TWICE.
>
>For example.... we are using the automounter to mount home directories onto
>the /home mount point.
>
>I am seeing ADSM backup the /export/home1/x directory AND the /home/x
>directory.
>
>I was expecting ADSM to backup only /export/home1/ not the mount point
>/home/x
>
>This is the response from IBM......quote
>
> -----FS-------+dir++-file-
> /export/home1/uXXXX/fileXX
> .
> -----FS-----+file+
> /home/uXXXX/fileXX
> .
> /home/uXXXX is pointing to /export/home1/uXXXX similar to a symbolic
> link (without the option FOLLOWSYMBOLIC=NO) as a filesystem of type
> LOFS. Now when ADSM is doing it's incremental it doesn't detect the
> LOFS filesystem type and thus is backing up the files from both
>filesystems it finds. This is a known restriction with this situation
>(since version 2 already) and there are plans by another customer to
>open a DCR on that.
>
>.....unquote
>
>I do not know if this problem is a SUN solaris problem only or if it works
>in this way on other unix platforms. IBM are saying that it is working as
>designed and to open a data change request (DCR)
>
>Our environment is
>
>ADSM server O/S:    OS/390 2.4
>ADSM server:        ADSM for MVS 2.1.0.13
>ADSM client O/S:    Sun Solaris 2.5.1
>ADSM client:        3.1.0.3
>
>Regards
>
>Gavin
>
>===========================================================================
====
>
>
>> From owner-adsm-l AT VM.MARIST DOT EDU  Fri Jun 19 10:35:49 1998
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 8bit
>> Date: Fri, 19 Jun 1998 11:26:39 +0200
>> From: Eckhard Trinkaus <trinkaus AT HRZ.UNI-MARBURG DOT DE>
>> Subject: problem with solaris 2.6
>> Comments: cc: Eckhard Trinkaus <trinkaus AT surz22.HRZ.Uni-Marburg DOT DE>
>> To: ADSM-L AT VM.MARIST DOT EDU
>>
>> Please help me to understand the following problem:
>>
>> We are running
>> ADSM server 2.1.0.18,
>> ADSM client 3.1.0.3 (Solaris 2.6)
>>
>> DOMAIN is all-local in dsm.opt,
>> there is no AUTOMOUNT option in dsm.sys
>>
>> /export is a local filesystem,
>> my home directory /export/home/trinkaus is mounted on /home/trinkaus
>> via automounter.
>>
>> The following commands are excuted by root:
>>
>>
>> dsmc selective /export/home/trinkaus/f
>> and
>> dsmc selective /home/trinkaus/f
>>
>> are generating two different active backups of file f
>> (with different backup time stamps).
>>
>> dsmc incremental
>>
>> expires both backups (to status inactive).
>>
>> I don't understand why the backup of /export/home/trinkaus/f becomes
inactive.
>>
>> With kind regards
>>
>> Eckhard Trinkaus
>>
>> ********************************************************
>> Eckhard Trinkaus
>> Hochschulrechenzentrum der Philipps-Universitaet Marburg
>> Hans-Meerwein-Strasse D35032 Marburg/Lahn
>> Bundesrepublik Deutschland
>> Tel.:  +49 6421 281554 / Fax: +49 6421 286994
>> Email: trinkaus AT hrz.uni-marburg DOT de
>> ********************************************************
>>
>
>
<Prev in Thread] Current Thread [Next in Thread>