ADSM-L

Re: AFS or DFS anyone?

1999-03-18 14:43:43
Subject: Re: AFS or DFS anyone?
From: "Purdon, James" <james_purdon AT MERCK DOT COM>
Date: Thu, 18 Mar 1999 14:43:43 -0500
Hi Helmut,
  You mentioned Cray-DFS below.  Do have an ADSM client for your Cray, and
if so what is its version/release level?

   We have Version 2, Release 1, Level 0.5.

Thanks,
Jim

> ----------
> From:         Helmut Richter[SMTP:Helmut.Richter AT LRZ-MUENCHEN DOT DE]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Thursday, March 18, 1999 2:14 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: AFS or DFS anyone?
>
> On Thu, 18 Mar 1999, Prather, Wanda wrote:
>
> > I don't think IBM has much interest in getting it to work well.  The
> > documentation is lousy, and the design appears to me to be very much a
> > patch/kludge, because as Reinhard noted, you have to maintain a zillion
> > virtual mount points manually to support your users properly, and there
> is
> > no good way to do it. IBM doesn't seem to have much grasp on how people
> > really use DFS in real-world environments that support lots of users.
>
> We discussed that at length with IBM when we introduced ADSM in 1995 (to
> no avail as usual). We now strongly discourage the use of the GUI. In the
> command line interface, the difference is not quite so big: people have to
> type in the full path, so they are less tempted to have ADSM search for
> hours (literally! can happen with one wrong click in the GUI)  through
> portions of the file space where none of their files reside.
>
> > So we run the BUTA interface, not by choice, but because that is what
> works.
> > SO users have no access to ADSM for file-level backup and restore, we
> have
> > do to it for them.  So they have no access to archiving, so they don't
> have
> > the problem you describe.
>
> We use BUTA as well, but are perfectly happy with it. We terminated
> file-level backup quite some time ago because it was hardly used: with
> AFS, you have the version of the day before always still mounted, so that
> *per individual user* a restore is a very rare operation. The user will
> then call us anyway, and it does not make much difference whether to
> explain it to them or to do it ourselves. When we have spare time, we
> might make a automatically processed Web interface for restoration
> wishes.
>
> With archive, things are different. There are not too many users using it,
> but those who do it do it on a regular basis and must be able to do it
> without aid from our side.
>
> On the other hand, we are fairly happy with the non-AFS/DFS-aware clients
> - errr.. we *were* happy as long as they worked. Users do not normally
> archive whole volumes/file-sets, and they may restore their access control
> lists themselves when they at least get their data back (this is more a
> DFS than an AFS problem as the latter has no file-level ACLs). If IBM
> wants to spare the effort of supporting AFS and DFS, we - I am not
> speaking for other customers - invite them do so: if an ADSM client is
> able to read a file back from where it was written to, that would solve
> most of the problem, and it would match what is promised in the manual.
> Additional support of AFS/DFS specifics would be great, of course, but not
> *vital*. But the current (non-vital: lethal) situation is that ADSM won't
> give you back your AFS or DFS file *because* it is AFS or DFS, although
> you did not ask that it be processed any different from any other file.
>
> > So far, all our DFS systems are AIX-only.
>
> Servers yes. But here we have a client problem, and clients are very
> diverse, even comprising hosts where the ADSM client is not officially
> supported (Linux with AFS, Cray with DFS, Fujitsu VPP with DFS (to come),
> ...).
>
> 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>