[49] in Athena_Backup_System
[Jonathon Weiss: Issues raised at the "High-Level Design" review]
daemon@ATHENA.MIT.EDU (Tim McGovern)
Thu Dec 8 09:00:00 1994
Date: Thu, 8 Dec 1994 08:58:37 -0500
To: athena-backup@MIT.EDU
From: tjm@MIT.EDU (Tim McGovern)
>Received: from SOUTH-STATION-ANNEX.MIT.EDU by EAGLE.MIT.EDU with SMTP
> id AA07826; Sat, 3 Dec 94 13:15:11 EST
>Received: from CHICH.MIT.EDU by MIT.EDU with SMTP
> id AA03607; Sat, 3 Dec 94 13:15:10 EST
>Received: by chich.MIT.EDU (5.57/4.7) id AA04532; Sat, 3 Dec 94 13:15:09 -0500
>Message-Id: <9412031815.AA04532@chich.MIT.EDU>
>To: jis@MIT.EDU, tytso@MIT.EDU
>Cc: dcnsm@MIT.EDU, dkk@MIT.EDU
>Subject: [Jonathon Weiss: Issues raised at the "High-Level Design" review]
>Date: Sat, 03 Dec 1994 13:15:08 EST
>From: Kimberly Carney <kim@MIT.EDU>
>
>
>I think the athena backup group is wanting to move ahead on a few
>things. Are you folks happy with the technical direction their taking?
>
>At this point the only other design issue I'm aware of is the use of
>the vldb. I believe the initial plan was to dump the vldb to get the
>list of volumes for the backup system on a fairly frequent basis. I
>think the plan is to now dump the vldb less frequently, something on
>the order of once per backup cycle.
>
>------- Forwarded Message
>
>Replied: Sat, 03 Dec 1994 12:50:05 EST
>Replied: "Jonathon Weiss <jweiss@MIT.EDU> athena-backup@MIT.EDU"
>Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by e40-po.MIT.EDU (5.61/4.7)
>id AA23000; Fri, 2 Dec 94 15:54:26 EST
>Received: from THE-OTHER-WOMAN.MIT.EDU by MIT.EDU with SMTP
> id AA13382; Fri, 2 Dec 94 15:54:25 EST
>Received: by the-other-woman.MIT.EDU (8.6.9/4.7.1)
> id PAA02996; Fri, 2 Dec 1994 15:54:24 -0500
>Message-Id: <199412022054.PAA02996@the-other-woman.MIT.EDU>
>From: Jonathon Weiss <jweiss@MIT.EDU>
>To: athena-backup@MIT.EDU
>Subject: Issues raised at the "High-Level Design" review
>Date: Fri, 02 Dec 1994 15:54:23 EST
>Sender: jweiss@MIT.EDU
>
>
>There were several issues brought up at the design review that took
>place several months ago. The most notable of these issues were our
>plans to use three technologies not developed in I/S. Have we
>addressed all of these issues? I am concerned that when we hold a
>review of the next stage of the project, there may be people upset by
>the fact that we have not addressed all of the issues. The pessimist
>in me worries that someone will decide that what we are doing is
>useless if we have not addressed all of these issues. I am not saying
>that this is likely, just that we should do what we can to make sure
>it does not happen.
>
> Paranoidly,
> Jonathon
>
>------- End of Forwarded Message
>
>=> Date: Fri, 02 Dec 1994 18:05:56 EST
>=> To: athena-backup@MIT.EDU
>=>
>=> From: Diane Delgado <delgado@MIT.EDU>
>=> Subject: Re: Issues raised at the "High-Level Design" review
>=>
>=> In-Reply-To: Your message of "Fri, 02 Dec 1994 15:54:23 EST."
>=> <199412022054.PAA02996@the-other-woman.MIT.EDU>
>=> Content-Length: 5908
>=>
>=>
>=> >There were several issues brought up at the design review that took
>=> >place several months ago. The most notable of these issues were our
>=> >plans to use three technologies not developed in I/S. Have we
>=> >addressed all of these issues?
>=>
>=> I agree; it's good to review these to be sure that we have everything
>=> understood, since I'd bet someone will undoubtedly raise the same issues.
>=> Feel free to add any more info:
>=>
>=> ONC - It's my understanding that (most) people agreed during the
>=> end of the review and after the review that ONC is perfectly
>=> acceptable for us to use.
>=>
>=> Concerns about ONC:
>=>
>=> 1. Source access - Peple felt more at ease if we have this.
>=> We do have source for ONC. I currently have two versions,
>=> the latest and a bsd-based version which is a few years old.
>=> The goal is to use the lastest version on those systems
>=> which support the X/TI interface (X/Open Transport Interface)
>=> (SOLARIS, AIX, ULTRIX). The old sockets based version would
>=> be used if we need to port to something that does not
>=> support this. The versions claim to be interoperable.
>=>
>=> 2. Documentation - Both versions of ONC come with the following
>=> documentation: man pages, application developer guides, and
>=> a short paper describing the implementation of the new version.
>=>
>=> 3. Learning Curve - ONC is a fairly simple protocol which is layered
>=> on top of sockets or streams. I've spent a lot of time looking
>=> at the code recently and I didn't find the learning curve to
>=> be high at all. (My experience has been as user of various RPC's with a
>=> small/moderate exposure to RPC internals).
>=>
>=> I've been also keeping notes as I've been doing the porting
>=> so anyone who needs to read the ONC code will know what we
>=> had to change.
>=>
>=>
>=> 4. I will leave MIT and no one will know how ONC works - I'm not
>=> planning on leaving soon, and secondly anyone who is on the
>=> implementation team will be highly familiar with ONC from a
>=> development/debugging point of view by time we are through, so
>=> the knowlege will be spreading amongst several people.
>=>
>=>
>=> 5. The technology isn't standard - Well it is a standard, in fact
>=> It's an IETF standard. It's also shipped by almost every unix
>=> vendor. The only minus is that the vendor code isn't usually
>=> kerberized, which is what we will be doing.
>=>
>=>
>=> Commercial Database
>=>
>=> This wasn't decided at the review, but somehow was resolved outside
>=> of the review. I heard rumors about how, but I'm not going to repeat
>=> them. Tim probably can comment more on the conjecture that this
>=> issue has been resolved and that people understand why we are going
>=> this route.
>=>
>=> I also note that during the review, those who objected most also
>=> described the public domain databases as "garbage", so no-one has
>=> yet come up with a better alternative.
>=>
>=>
>=> Threads
>=>
>=> This was the only item of the three which was subject to compromise.
>=> One valid objection centered around the use of threads with the
>=> DBMS libraries, and that all DBMS vendors don't support threads
>=> safe client DBMS libraries. So what we've done here is to not
>=> have a fully threaded master server which can handle multiple calls.
>=> The design and implementation will, however, take into account the
>=> fact that we may need to implement full threads support in the
>=> future. Thus we program in a threads-safe fashion, although we
>=> aren't really using threads at this time.
>=>
>=> We do use two threads in the Master server, one for all of the main
>=> server work and a second thread which initiates the automated jobs.
>=> This isn't a problem for the following reasons:
>=>
>=> 1. The scope of the auto job thread is limited and there isn't
>=> expected to be a lot of overlap with other work in the master.
>=> The interaction between the two threads will be limited and
>=> not hairy.
>=>
>=> 2. The use of threads in this case is very simple and easy to
>=> understand, and it's a good introduction to threads for
>=> the person who will be implementing it.
>=>
>=> 3. The threads implementation is more elegant than other options
>=> (e.g., signals) and its interaction with other things like the
>=> dbms libraries is more predictable.
>=>
>=> To implement automatic job scheduling, what we are really doing
>=> is performing a context switch wherein at a pre-appointed time,
>=> we stop what we are doing and perform a different task which is
>=> the initiation of the automatic jobs, and then resume the previous
>=> task. The simplist way to effect this context switch is via
>threads,
>=> since it's already done for us by the threads package.
>=>
>=> Since the target platform for the master is solaris and solaris
>=> has native threads, we might as well take advatage of them.
>=> I've actually prototyped this and it works.
>=>
>=> 4. Porting issues - For the Master, it isn't necessary that it run
>=> on all platforms. If we need to migrate there are a few options:
>=>
>=> a. use the target vendor's threads, if they exist. It isn't
>=> uncommon for threads to exist so this is a possiblity.
>=>
>=> b. Use user-space threads - we have a user space threads package
>=> that we can port to platforms (DCE threads, which is already
>=> ported to rios, hpux, mips).
>=>
>=> c. Emulated the functionality someother way with signals
>=> or whatever else is available.
>=>
>=> 5. Note that the lastest version of the ONC-RPC library has been
>=> made threads safe!
>=>
>=> The last threads objection to address is : no one in dcns-dev knows
>=> how to program with threads. This is not true. I've programmed with
>=> threads, and guess what AFS is based on threads, so surely someone
>=> here knows AFS? Thinking about threads while programming will also
>=> introduce some good programming habits, such as using global variables
>=> sparingly which contributes to readability.
>
>=> Date: Sat, 03 Dec 1994 12:50:05 EST
>=> To: Jonathon Weiss <jweiss@MIT.EDU>
>=> cc: athena-backup@MIT.EDU
>=>
>=> From: Kimberly Carney <kim@MIT.EDU>
>=> Subject: Re: Issues raised at the "High-Level Design" review
>=>
>=> In-Reply-To: Your message of Fri, 02 Dec 1994 15:54:23 -0500.
>=> <199412022054.PAA02996@the-other-woman.MIT.EDU>
>=>
>=>
>=> Jonathon,
>=>
>=> Thanks for being paranoid--it's good to raise a flag about stuff now
>=> rather than later. :)
>=>
>=> Diane brought up three issues: threads, onc, and the use of a
>=> relational database. Are there any other issues, raised at the design
>=> review or perhaps cropped up later, the abs group needs clarification
>=> on?
>
>
>
>
>
>
>
>
>
>
>
>
