Helmut Richter writes:
> We have reproducibly the following situation:
>
> 1. A user issues the command
> dsmc archive -subdir=yes "/a/b/c/*"
> and gets the response that a number of files have been
> successfully archived.
>
> 2. Immediately afterwards, the same user on the same machine issues
> the command
> dsmc query archive -subdir=yes "/a/b/c/*"
> and gets the response that no files were found.
>
> Our investigation shows that the first command has stored the data in
> filespace "/a" but the second command searches the files in filespace
> "/a/b". Note that both filespaces have existed prior to both commands
> and the set of filespaces did never change during the whole operation.
> Prior to this incident, we thought that such problems could only occur
> when new filespaces are created.
>
> We are now at a loss when we try to document ADSM to our customers in
> a way that they could resolve such cases. We *do not know* how ADSM
> works in this respect, and even if we did, we could probably not
> describe ADSM's behaviour in a way that would be intelligible for the
> customer who just wants to archive and retrieve his data without
> bothering about filespaces.
>
> Who can help us?
>
> We are particularly interested in the following questions:
>
> - What are the configurations that would lead to the situation described
> above?
>
> - What methods are there to repair such a situation without the risk of
> losing data in any of the affected filespaces?
>
> - Where is the behaviour of ADSM documented as far as filespaces are
> concerned, and this in sufficient detail to allow us to understand
> the situation we are in?
>
> Thanks in advance for any assistance you are willing to give us.
>
> Best regards,
>
> Helmut Richter
I tried recreating your scenario and could not. In my case, I created
a file system /usr/a/b/c and put some files in it. I then archived
them with:
dsmc archive "/usr/a/b/c/*" -subdir=yes
I then did:
dsmc query archive "/usr/a/b/c/*" -subdir=yes
And got a listing of the files I had just archived. Specifying just
"/usr/*" didn't give me any files.
This behavior corresponds with how ADSM is supposed to behave, and
with my own past observations. However, I did my testing on an AIX
system (AIX 3.2.5, to be exact). If you're working with a different
UNIX platform, I'll try to recreate there.
I also forwarded your question to MJ Lopatin of ADSM development, and
she asked me to post the following information here. This information
was supposed to go into the README files, but apparently didn't get
put in for some reason (although we think it's in the NEC README file).
This should be corrected in future PTFs. Here is the information:
=======================================================================
ADSM Stores Files in File Spaces
When you back up and archive files, ADSM stores the
backups and archives in a file space in ADSM storage that
has the same name as the file system or virtual mount
point from which the files originated.
For example, if you have a file system named /HOME, and
you back up a file named DOC1 in the /HOME/JONES direc-
tory, ADSM stores the file in a file space named /HOME.
However, if a root user subsequently defines /HOME/JONES
as a virtual mount point, any files you back up from the
/HOME/JONES directory, such as DOC2, are stored in a file
space named /HOME/JONES.
If you enter this command:
dsmc query backup /home/jones/*
ADSM looks for files in the /HOME/JONES file space. It
always looks for a file in the file space with the
longest name that matches the file specification you
include in a command. It finds the file named DOC2 that
was backed up after the virtual mount point was defined.
_____
However, it does not find the file named DOC1 because
that file was backed up before the virtual mount point
______
was defined, and the backup was stored in the /HOME file
space.
To list or restore the DOC1 file using a command, you
must specify the file space name explicitly by enclosing
it in braces. For example:
dsmc query backup {/home}/jones/*
dsmc restore {/home}/jones/doc1
If the root user subsequently removes the /HOME/JONES
virtual mount point, and you then back up additional
files in the /HOME/JONES directory, the backups are once
again stored in the /HOME file space. For example, if
you now back up a file named DOC3 in the /HOME/JONES
directory, it is stored in the /HOME file space. It is
not stored in the existing /HOME/JONES file space.
However, because the /HOME/JONES file space already
exists, when you try to list or restore the DOC3 file,
ADSM looks in the /HOME/JONES file space for the file
unless you specify the correct file space name as
follows:
dsmc query backup {/home}/jones/*
dsmc restore {/home}/jones/doc2
NOTE: You must specify the file space name explicitly
only when there can be more than one resolution to the
file specification you enter.
Here is another example. If these file spaces exist in
ADSM storage:
/home
/home/jones
/home/jones/project1
/home/jones/project1/planning
and you enter this command:
dsmc query backup /home/jones/project1/planning/*
ADSM looks for files only in the
/HOME/JONES/PROJECT1/PLANNING file space, even if one or
more of the other file spaces contains a path with the
same name. But, if you enter:
dsmc query backup {/home}/jones/project1/planning/*
ADSM looks for files only in the /HOME file space.
Or, if you enter one of the following:
dsmc query backup {/home/jones}/project1/planning/*
dsmc query backup {/home/jones/project1}/planning/*
ADSM looks for files only in the /HOME/JONES file space
or the /HOME/JONES/PROJECT1 file space.
|
