[MUD-Dev] The grass is always greener in the other field

[Cynbe ru Taren]

"Bruce Mitchener, Jr." <bruce at puremagic.com> wrote:

| I think that this problem (storage of objects that are being hoarded or
| otherwise stored away, outside of common day-to-day usage) can be solved on
| the technology side of things.

Here's what I'm thinking of for Muq along those lines:

*  Monolithic garbage collection &tc of ram-cached objects, because
   it saves me writing expensive read and write barriers on in-ram
   operations, but

*  Incremental operations on the larger disk db, in particular incremental
   garbage collection and incremental disk backup, and

*  Optionally, beyond the first generation of backup, storing backups
   using RCS or CVS or such.  Muq's on-disk garbage collection does
   not compact or rename, and zeros out free blocks to improve
   compression and such, so vanilla the binary-capable GNU diff that RCS
   and CVS depend on should do a good job of storing only significant
   changes when used this way.

This should achieve much of you want relatively cheaply:

*  The bulk of the server is unaffected because no new invariants
   involving in-ram operations on in-ram data are required.  Thus,
   server performance is nearly unaffected.

*  Incremental backup and garbage collection of the on-disk part of
   the db does require server hacks, but they can be confined to the
   diskbase logic doing object load/store and are fairly simple, so
   this is not an onerous coding task.

*  The job of avoiding massive db duplication on disk by adopting a
   logging sort of approach is moved entirely out of the server and
   simply leverages pre-existing cvs/rcs/diff logic, yielding good
   results with minimal coding effort or complexity.  They'll run
   in batch mode, but as an independent process, if need be on a
   separate machine, so they again don't impact server performance.

I'm thinking about coding up the incremental global gc this weekend.

The independent in-ram-generation monotlithic gc might follow shortly.

I've no very immediate plans to code up the CVS/RCS/diff support any
time soon, since Muq is a long way from having a pressing need for it,
but that should be pretty much a one-evening hack when the time comes.

Net result should be that accumulated unused objects just cost you a
fixed amount of disk space: They don't show up in ram and they don't
show up repeatedly in your backups, except to increase compute time
for them in linear fashion.  On that basis, an UOL scale operation
should be able to afford gigabytes of background junk without strain,
and terabytes without much problem.  No?

 Cynbe



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev