Re: [CODE]..

From: Del (
Date: 06/19/00

Chris Gilbert wrote:
> As this all started from an OS class I'd have thought that someone would
> point out that the above is just wrong in a modern OS.  A modern OS
> stores a lot of the info on the disks in memory, and uses a buffer to do
> read and writes to.  This is why you have to shut them down properly.
> IE when you open the file it does do a bit of disk activity, but is more
> likely to delay the write by buffering it until it's got a bit of free
> CPU time to do the write.  Hence the need to sync disks during shutdown.
> I'm not sure how old the olc code is, but circlemud is 5-6 years old,
> that long ago memory wasn't cheap, processes weren't as fast, in that
> time we've come from 486's to PIII's, a std computer now comes with 64MB
> not 4MB.  In those days doing disk writes was expensive as you couldn't
> buffer as much in memory, that's why the save internal is probably
> there, to act as a buffer.
> >    'saving internally' simply means updating the online status; there is
> > such a thing as making a temporary change to something and not
> > wanting the change to be a permanent one -- once you save to disk, the
> > change is committed meaning 'no matter how bad' it is you can only
> > revert if you have a backup.
> Oasis 2 actually does a save of everything on a shutdown, so eventually
> all changes in memory get written out.
> >     And being a little buggy means you -definitely- shouldn't save after
> > every edit, and you should prolly backup and diff the changes between saved
> > and pre-save copy just to be safe.
> Oddly enough most builders I know save after virtually every edit as OLC
> is generally considered fairly unstable, hence a lot of muds have
> builders ports. It's improved a lot with Oasis 2 in terms of stability
> though :)

As you stated the newer hardware speed factors, and memory size has
over the years. These factors used to be a consideration on designing a
of codes. This factor is minimal, when saving a zone (redit, zedit, etc)
entire mud is not saved when the call to save_to_disk is used. Also
was the fact that the more experienced builders save almost every change
manually. Even at one point I had triggers setup to do it for me.
I saw no slow downs, lags, etc. Each save went as quick as could be. I
am no
expert on memory management nor processor time management, however
with the code and circle for many years, it certainly has come a long
with the use of 32+M memory and pentium processors. Meaning, it seems
the speed and memory factors are no longer a considerable factor in
some code.
A shutdown (reboot) is not the only reason a builder needs to save
often (if not after each change). Crashes (being most common reason for
of work) and power losses are a good reason for saving each change. The
of reverting back to an original version is a small factor. If someone
up an object/mob/room/shop it will not effect the entire zone/world. The
is minimal and rarely would need a complete restore. Daily backups
handle most if not all restore problems.
IMO - Saving after every change has its definite advantage. Loss of work
totaly bites.

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT