[DGD] Persistent Users

[bart at wotf.org]

On Thu, 22 Sep 2016 10:02:54 -0500, Blain wrote
> Bart, if your password and permissions info is stored in a database
> separate from the user object, then that's still not in the swap.  ;)
>   It's just in a large database file.

That database is written in LPC, runs inside the virtual machine, and lives in
swap except for the few things currently being referenced.

> 
> I get that people don't mind putting all of their eggs in one basket.

Its not all in one basket. The database supports keeping a replica of itself
on a different instance of the codebase, and supports exporting the data in
json format for cases where you might want to edit it manually, and for
safekeeping.

Both methods are more efficient then using .o files.

> Keeping individual files on disk is still one big basket that is the 
> disk. And it's not like the OS or HDD itself can't cause corruption. 
>  But on Ancient Anguish, we had a rash of problems for nearly a year 
> where individual player files were getting corrupted because the HDD 
> was caching the write job but never fulfilling it in some cases. 

That sounds like a bad HDD, and something your OS should have caught.

>  Imagine if one large file was being corrupted due to this.  A lot 
> of this really depends on the technology involved and whether or not 
> the data is recoverable or replaceable from backup.  If you can 
> retrieve the info for a single user from a corrupted swapfile, then 
> there's no problem.  I can't.  I'm not savvy enough.  But I can 
> handle individual files all day long.

Well, I can, but haven't done so in many years. The last time I encountered
corruption in swap (actually, state dump) was some decade ago when dgd 1.2.13x
was very current, and repairing it actually involved patching the state dump
loader from dgd. 

This can certainly be a legitimate concern, but when it is your hardware
messing up due to not writing data back to disk, or writing corrupt data,
anything can happen, and being able to repair this by editing or restoring
some individual .o files sounds like you have been lucky. It might as well
have caused corruption in other files.

One thing to consider is to ensure you make regular backups of the state dump
to some other location, and try to restore it there (backups are nice.. but
useless unless you are sure you can restore them).

ANother possible solution, but one which is probably not suitable for your
typical mud, is to replicate the data to a second dgd instance. Its something
I'm playing with a lot, but it ties in very well to my original goal, making
something for releasing my I3 router code.. The I3 routers already need such
things because they are part of a network of multiple redundant routers which
share mudlist and channel list data.

Distributed data however is yet one step further, and not something I believe
any classic lpmud will ever need. Its fun to play with tho.

Bart.
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/