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
changed
over the years. These factors used to be a consideration on designing a
lot
of codes. This factor is minimal, when saving a zone (redit, zedit, etc)
the
entire mud is not saved when the call to save_to_disk is used. Also
stated
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
working
with the code and circle for many years, it certainly has come a long
way
with the use of 32+M memory and pentium processors. Meaning, it seems
that
the speed and memory factors are no longer a considerable factor in
designing
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
loss
of work) and power losses are a good reason for saving each change. The
logic
of reverting back to an original version is a small factor. If someone
messes
up an object/mob/room/shop it will not effect the entire zone/world. The
fix
is minimal and rarely would need a complete restore. Daily backups
should
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: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT