[MUD-Dev] The grass is always greener in the other field
Cynbe ru Taren
cynbe at muq.org
Thu Dec 16 16:44:49 New Zealand Daylight Time 1999
"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
* 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?
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev