ADSM, symbolic links, and file spaces
1996-05-28 09:54:08
Hello,
has anyone an idea how to work with filespaces under Unix? Consider the
following problem as an example (it is a real problem from one of our
customers, not a constructed one, and it took us quite some time to
analyze, although we found no solution):
The customer writes:
When I do a 'dsmc query archive -subdir "./*"' I see a different and
disjoint set of files from a 'dsmc query archive -subdir "$HOME/*"'
although my home directory is the current working directory.
The reason we found out is that ADSM stores files according to their paths
that may contain symbolic links. The shell (and different shells or the
same shell on different Unices may disagree) seems to resolve symbolic
links in the "." but not so symbolic links in "$HOME" or vice versa.
Hence, files stored as "./something" are found under "./*" and files
stored under "$HOME/something" are found under "$HOME/*" but in both cases
not vice versa. One half of the files of this user is stored with names
"/afs/lrz-muenchen.de/home/u/u123456/..." in the file space mounted at
"/afs/lrz-muenchen.de/home/u", the other half is stored under names
"/afs/lrz/home/u/u123456/..." and thus not in this file space. "/afs/lrz"
is a symbolic link to "/afs/lrz-muenchen.de". This is *not* a problem of
AFS (which is only marginally supported under ADSM anyway) but the same
problem can occur under ordinary Unix file systems as well: there, too,
symbolic links in paths of home directories are frequently used to
encapsulate names of physical devices that have no bearing for the end
user.
There is no obvious solution:
Not defining vitual mount points underneath /afs would mean that the
entirety of all AFS cells worldwide would form a single file space.
Dropping the symbolic link would render thousands of file paths wrong.
There is no way to force, persuade, or teach users to consistently use
one version of the file path or the other: all other applications except
ADSM know how symbolic links work and act consistently. This is an
ADSM-only problem.
The only solution we have so far seen would be to write our own version
of "dsmc query" which spawns as many "dsmc" processes as there are file
spaces (now 35) and then combines the results. But this is a waste of both
human and computer resources.
Writing a PMR or DCE to fix this bug is, according to all our
experience, waste of time and effort: it is nowhere explicitly promised
that this bug does not exist, so everything is "working as designed", even
if ill-designed.
If other customers have run into the same problem and found solutions, we
would very much appreciate their assistance.
Also, we would appreciate if IBM could document how file spaces are defined:
by the virtual mountpoints currently defined at the requesting client
by the virtual mointpoints defined at the archiving client at the time
of archive
by the union of the sets of virtual mountpoints ever defined at any client
by a combination of the above (e.g. file space is determined the third
way but not changed if new mount points emerge after storage).
Best regards,
Helmut Richter
==============================================================
Dr. Helmut Richter Leibniz-Rechenzentrum
Tel: +49-89-289-28785 Barer Str. 21
Fax: +49-89-2809460 D-80333 Muenchen
Email: Helmut.Richter AT lrz-muenchen DOT de Germany
==============================================================
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- ADSM, symbolic links, and file spaces,
Helmut Richter <=
|
|
|