Subject: Re: Suggestion for 1.8.0

From: jonathan@nova (Jonathan Bradshaw)
Date: Wed, 13 Oct 1993 16:37:43 -0700

> As long-time readers of this list are aware, release 1.9.0 of the
> server will maintain the database on disk.

Actually, long time readers would be aware 1.8.0 was meant to be the version
with disk basing. <grin> And that was last estimated this year. 

<sigh> I guess we wait longer for disk basing. Maybe the next presidential
election?

For me, disk basing has one VERY needed feature. The bug in the NeXT that
causes malloc() panics is a LARGE problem. Its one which would be solved
by disk basing (or so Pavel says).

-- 
 Jonathan Bradshaw | Preferred E-Mail is: [email-masked] | Ham N9OXE
 WNDU-AM/FM/TV South Bend IN | Opinions stated are mine and not of my employer
 PGP 2.2 Key fingerprint is:  EA 16 1B 5D 5D 94 6B 06  58 FD E6 E9 52 F3 6E 11
 "If any girl rejects you, don't you doubt it's part of the .plan" - D. Gibson

---

From: Jerry Weiler <[email-masked]>
Date: Wed, 13 Oct 1993 18:10:10 -0700

well, here's the relevent part of a message Pavel sent a few months ago:

  [ ...some headers deleted... ]
  Date:   Tue, 6 Jul 1993 10:52:29 -0700
  From:   Pavel Curtis <[email-masked]>
  To:     [email-masked]
  cc:     [email-masked]
  Subject: Re: Breaking the silence

  [ ...network and NeXT vm discussion deleted... ]

  >   When will the next release of the MOO server be out?  And when is
  > disk-basing going to be an option?

  Version 1.8.0 of the server, including error signalling and handling,
  significantly improved network support (probably including support for
  running network *servers* from MOO code), many bug fixes and
  substantial cleanup of some key internal interfaces (including the one
  to the DB storage method), will be probably be released sometime this
  fall.

  Version 1.9.0, including support for disk-based DB storage, will
  probably come out sometime in the early winter.

  Please note the word `probably' in the above time estimates.  I have
  way too many demands on my time right now and can't commit to anything
  more than vague estimates; in particular, it's possible that there
  won't be any new server releases anytime this year.  The above
  estimates, though, are my current best guesses.

          Pavel

- Jerry
(Lynx@LambdaMOO)

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 14 Oct 1993 08:10:54 -0700

> Date:	Wed, 13 Oct 1993 16:37:43 -0700
> From:	jonathan@nova (Jonathan Bradshaw)
> 

Um, I don't recall saying that disk-basing would necessarily solve this
problem, though it might very well partially ameliorate it.  As far as I can
tell, the NeXT bug would infect any sufficiently long-running allocating
program.

	Pavel

---

From: [email-masked] (Jonathan Bradshaw)
Date: Thu, 14 Oct 1993 12:10:14 -0700

> problem, though it might very well partially ameliorate it.  As far as I
can > tell, the NeXT bug would infect any sufficiently long-running
allocating > program. 

True, but I would not lose data each time it crashed (or at least, little)
rather than an hour of change.

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 14 Oct 1993 13:46:13 -0700

> rather than an hour of change.

Actually, that's no different for the disk-based case than it is now, except
that since the equivalent of `checkpointing' will be so much cheaper, people
will be more willing to do it more frequently.

Even in the new system, the server will occasionally make everything consistent
on disk, fork a process to copy the disk file to another, forever stable, copy,
and treat the DB file as read-only until that forked copier completes.  Absent
a log-based full-blown database file implementation (which I don't propose to
write), this is the only way I can think of to have there be a consistent image
on disk both for backup purposes and in case of a server crash.

My measurements on LambdaMOO on the old hardware (SPARCstation 2) showed that
that forked copier would run for only about a minute and a half, even for a DB
of that size.  Further, there was no perceptible lag on the MOO while that copy
was being made.

	Pavel