[53] in Athena_Backup_System
Kim's concerns re: Backup project
daemon@ATHENA.MIT.EDU (Tim McGovern)
Thu Dec 8 09:25:09 1994
Date: Thu, 8 Dec 1994 09:23:42 -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 AA23823; Mon, 5 Dec 94 20:11:59 EST
>Received: from CHICH.MIT.EDU by MIT.EDU with SMTP
> id AA22444; Mon, 5 Dec 94 20:11:57 EST
>Received: by chich.MIT.EDU (5.57/4.7) id AA06539; Mon, 5 Dec 94 20:11:57 -0500
>Message-Id: <9412060111.AA06539@chich.MIT.EDU>
>To: tjm@MIT.EDU, cec@MIT.EDU
>Subject: ["Theodore Ts'o": Re: [Jonathon Weiss: Issues raised at the
>"High-Level Design" review]]
>Date: Mon, 05 Dec 1994 20:11:55 EST
>From: Kimberly Carney <kim@MIT.EDU>
>
>
>I think someone needs to get Ted and Diane talking, and someone on the
>project team needs to make sure that staff get responded to as issues,
>questions, or concerns are raised.
>
>I'm excited about the new backup system, as I think others are. I'd
>hate to see this project lose momentum.
>
>Any suggestions?
>
>------- Forwarded Message
>
>Received: from SOUTH-STATION-ANNEX.MIT.EDU by e40-po.MIT.EDU (5.61/4.7) id
>AA10605; Mon, 5 Dec 94 16:27:54 EST
>Received: from ietf-pers-25.ietf.toaster.net by MIT.EDU with SMTP
> id AA00158; Mon, 5 Dec 94 16:27:52 EST
>Received: by rsx-11.mit.edu (8.6.9/4.7) id QAA00262; Mon, 5 Dec 1994
>16:27:50 -0500
>Date: Mon, 5 Dec 1994 16:27:50 -0500
>From: "Theodore Ts'o" <tytso@MIT.EDU>
>Message-Id: <199412052127.QAA00262@rsx-11.mit.edu>
>To: kim@MIT.EDU
>Cc: jis@MIT.EDU, dcnsm@MIT.EDU, dkk@MIT.EDU
>In-Reply-To: <9412031815.AA04532@chich.MIT.EDU> (message from Kimberly
>Carney on Sat, 03 Dec 1994 13:15:08 EST)
>Subject: Re: [Jonathon Weiss: Issues raised at the "High-Level Design" review]
>Address: 1 Amherst St., Cambridge, MA 02139
>Phone: (617) 253-8091
>
> 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?
>
>As far as I'm concerned the Athena Backup Group has done nothing to try
>to address the concerns which I've raised at the last design meeting.
>Suggestions which I've sent to athena-backup mailing list have not been
>answered (at all), so it's very clear that my technical input is being
>ignored.
>
>Since no one is even replying to my mail sent to the athena-backup
>mailing list, and I've been fairly busy, I've given up closely following
>the progress of the Athena Backup group. However, reading Diane's
>analysis of the use of the three technologies in question, I have the
>following comments. I don't mind if these suggestions are also ignored,
>but I wouldn't be doing my job if I did not at least raise the issues.
>
>If the Athena Backup Team ends up using threads, I think that there is a
>very good chance that this path will lead to disaster. (The technical
>basis for this opinion is available upon request; the short version of
>it is that most of the our own libraries, including the Kerberos
>library, are *not* thread safe. The fact that Diane didn't even raise
>this as an issue in her assessment worries me. Even the limited use of
>threads may be problematical.)
>
>If they are using a relational database and RPC system, my technical
>opinion is that this will result in a system that will require more
>resources to do a robust, supportable job than if they did not,
>especially on a long-term, on-going basis, even if it takes less work
>up-front. This is not a disaster, as long as we actually are willing to
>commit the resources necessary to support the design which the team has
>chosen.
>
>One of the suggestions which I made to the Athena Backup team was that
>they should make an estimate for the amount of technical resources, both
>in terms of FTE's and dollars, that their design will require to support
>it an on-going basis. At that point, we should do whatever is necessary
>to make sure that those resources can be committed, so we don't run into
>the Moira problem of needing a full-time person to run it as a real,
>quality production service, and then running in to difficulties being
>able to wring out the necessary resources to do it right. I believe we
>should engage in those discussions *now* and if we can't commit those
>resources we should revisit the design, before the implementation phase,
>and possibly scale it back.
>
>The bottom line? As long as the necessary resources have been
>committed, and threads are *not* going to be used, I believe the Athena
>Backup Service has a good chance to actually work from a technical point
>of view.
>
> - Ted
>
>P.S. What's the next step? There has been a "high-level" design
>review, which operated at the 50,000 foot level. Is there going to be a
>more detailed design review which will cover the lower layer issues,
>such as the vldb issue which you brought up?
>
>------- End of Forwarded Message
>
>
