Hi Richard,
thanks for your reply.
---------------------------------------------------------------
follow the path given by the argument of dsmc, don't leave the
filesystem from nowon and treat what you find there as distinct
file"space"
---------------------------------------------------------------
So if I got you right, this is what adsm is *not* able to do ?
And that's no bug but a feature ??
(1) This means: I'm not supposed to use own namespace-concepts
like automouonter-maps underneath adsm
---------------------------------------------------------------
-> adsm and automounter are incompatible
---------------------------------------------------------------
To distinguish "local" from "network"space seems usefull in
M$- but not necessaryly in an Unix-Enviroment.
(2) This seems very clearly to be a bug:
- You specify a starting-path for an archive
- no symlink crosses this startingpoint
-> adsm searches the filesystem downward AND upward !
-> following every symlink from above the startingpoint
it covers the whole nfs-cluster.
"archive" does something the dsm-browser had shown
and that is not even is consequent within the
concept of seperate "local" and "network" space.
(3) Yes, that is what I would expect adsm to do:
treat os-defines filesystems 1:1 als seperate filespaces
According to my experience however adsm by default seems to
define the first part of the path-string as filespace.
Trying to force a seperation by using "virtualmountpoint"
results in duplicate/indistinguishable entries in the
dsm-browser.
btw: do the ibm-folks also read this list ?
Reinald
---------------------------------------------------------------
follow the path given by the argument of dsmc, don't leave the
filesystem from nowon and treat what you find there as distinct
file"space"
---------------------------------------------------------------
>Hi, Reinald
>
>I don't think this is a server problem, and I don't think it's specific
>to DEC-Unix. I operate in a SUN-Solaris environment.
>
>(1) I think this is the desired behavior. You don't want to backup
> NFS server files through the NFS client. Therefore, when the
> ADSM client executes an INCREMENTAL, it should not follow links
> onto remote systems. The NFS server should have its own backup
> schedule with the ADSM server.
>
>(2) I am not surprised by the archive behavior either. ARCHIVE uses
> the apparent name, and follows links to the bitter end. However,
> I cannot offer any further comment without knowing what you are
> trying to accomplish with the ARCHIVE command. I prefer to think
> of ARCHIVE as a tool for specific files, and BACKUP (e.g. INCREMENTAL)
> as the tool for filesystems.
>
>(3) I do not use VIRTUALMOUNTPOINT. I observe that filespaces are
> assigned to mountpoints as defined by the OS.
>
>Rich
>
>At 02:30 PM 7/1/99 +0200, you wrote:
>>I think about downgrading to Level 0.1 (IP21174.tar).
>>Could someone make this old version available ? Thanks.
>>
>>We encounter the following problems, especially with newer levels:
>>
>>(1) None of the 3.1 Clients
>> that distinguish between "Local" and "Network Filespace"
>> works in Digital-Unix automounter-enviroment.
>>
>> We tried
>> Version 3 Release 1, Level 0.3
>> Version 3 Release 1, Level 0.5
>> Version 3 Release 1, Level 0.6
>> Version 3 Release 1, Level 0.7 on Digital-Unix 4.0d
>> (Server is Version 3, Release 1, Level 2.20 on AIX-RS/6000)
>>
>> In all cases "Network Filespace" shows only the physical mountpoints
>> and does not follow the symlink of the logical paths
>>
>> (example:
>> elgon:/dist1/admin
>> is asignd to the logical path
>> /DIST/admin
>> the automounter-daemon on another node mounts this filesystem
>> dynamicaly to the physical mountpoint
>> /a/elgon/dist1/admin
>> and establisches a symbolic link
>> /DIST/admin/ -> /a/elgon/dist1/admin
>> -> adsm -clients is only able to follow the physical mountpoint,
>> which chandes if the disk migrates to another nfs-server)
>>
>>(2) trying do do an archive on "Local Filsspace"
>> /dist1/admin
>> (with /dev/rz0a /
>> (with /dev/rz0a /
>> /dev/rz0g /usr
>> /dev/rz5h /dist1 )
>>
>>
>> results not only in recursing subdirectories but to search the tree
>> in *both* directions. It does not even stay in the "Local Filespace"
>> but tends to cover the whole nfs-cluster, like
>> /dist1/admin/.../usr/local/CASE/xyz
>> (with /usr/local -> /DIST/alpha and
>> /DIST/alpha/bin/CASE -> /DIST/CASE,
>> no upward symlink across startingpoint )
>>
>>(3) I did not have much luck with the use of "virtualmountpoint" yet
>> on DEC-Unix.
>> (3.1) If I use in now in 3.1.05
>> virtualmountpoint /
>> virtualmountpoint /usr
>> dsm->Archive shows 2 identical / and
>> 2 identical /usr -entries. So what?
>> (3.2) do I have to use "virtualmountpoint" at all if I do a
>> dsmc /DIST/alpha followd by
>> dsmc /DIST/share
>> to make shure that both are kept sepearate?
>>
>> Are "Filespaces" asigned to the first section of the path
>> by default rather than to the filesystem as defined by the
>> operating system ? Is there a way to correct this ?
>>
>>
>> the desired behavior of the client is trivial:
>> ---------------------------------------------------------------
>> follow the path given by the argument of dsmc, don't leave the
>> filesystem from nowon and treat what you find there as distinct
>> file"space"
>> ---------------------------------------------------------------
>> ...
>>
>>
>>
>>Do you have any hints or comments ?
>>Do you have similar experiences with the DEC-Clients ?
>>Are the points mentioned above known to ibm or are they really unique ?
>>
>>Thanks for your reply in every case
>>
>> Reinald Gfuellner
>>
>>--
>>--.---------------------------------------------------------------------
>> 3~ Reinald Gfuellner PGP: use finger ..|.
>> Lehrstuhl fuer Prozessrechner, TU Muenchen, phone: +49-89-289-23564
>>----------gfullner AT lpr.ei.tum DOT
>>de-------------------fax:+49-89-289-23555-
>>
>>
>Richard C. Dempsey email: dempsey AT kodak DOT com
>Public Online Services pager: 716-975-3539
>11th Floor, Bldg 83, RL phone: 716-477-3457
>Eastman Kodak Company fax: 716-722-3885
>Rochester, NY 14650-2203
--
--.---------------------------------------------------------------------
--.---------------------------------------------------------------------
3~ Reinald Gfuellner PGP: use finger ..|.
3~ Reinald Gfuellner PGP: use finger ..|.
Lehrstuhl fuer Prozessrechner, TU Muenchen, phone: +49-89-289-23564
----------gfullner AT lpr.ei.tum DOT de-------------------fax:
+49-89-289-23555-
+49-89-289-23555-
|
