syncd v2.0
------------------------------------------------------------------------
Steve Conley, root@serpentine.dyn.ml.org
Serpentine Network Industries
[c]1998 Serpentine Network Industries
Availible under the Gnu Public Licencse
There's no reason for this to blow up, but if it does, it ain't my fault
------------------------------------------------------------------------


1. Introduction
	Now and then, our machines crash.  It happens to the best of us,
from the mighty UNIX Jedi to the lowest newbie hack.  We can't control
them, we can't necisarily prevent them, but we sure as hell don't like
them.  We ESPECIALLY don't like the nasty fsck messages we get when we
reboot, and the possibilty of lost data off our drive.
	Why, you ask, do we loose any data?  Well, the answer is easy;
Linux, bless its heart, saves anything you save on disk to a place in
memory.  When it can get around to it, it saves that data on the disk,
thus speeding things up--since while it's in memory, you can save and
read and write this file real fast without many disk lookups.  This is
called disk caching.  So, when you crash, you loose whatever's in that
cache, and Linux only knows whether or not you just lost something
important in there before it could save it to the drive.
	And what about those FSCK messages?  We've probably all seen
them; fsck runs at boot, takes 5 years to run, and belches things about
deleted inodes and other archane things.  That's gotta be bad.  So, I
got to thinking about how I could fix that; the answer is, syncd.

2. Okay, I know what you're doing, but what does syncd do?
	There's a UNIX command--namely sync--which tells Linux: HEY!
write those buffers to disk!  Type it at your prompt; you'll hear your
drive whirl a moment, and then you'll get your prompt back.  Whoopie.
Now, sync has a few problems, but we'll get to tht in a bit.  Running
sync, especially after you save something big, is a good idea.  It
prevents you from loosing data and it can potentially save you from
those nasty fsck messages if you crash.
	Syncd is a daemon, meaning that it runs in the background of your
system while you do other things, that simply runs sync periodically.
The default is once ever 5 minutes (note that there's nothing magical about
this number; you probably don't want to run sync too much more often than
every 5 mintues, as that would defeat the purpose of caching, which really
IS a good thing, so long as things are safe).  You can change it by running
it with an arguement; syncd <number of seconds you want to sleep between syncs>

3. You mentioned problems...?
	Yes, there's a major problem in sync, and thus in syncd.  Sync only
scheduals a save--it doesn't do it the -second- you hit sync, but shortly
thereafter.  In other words, it taps Linux on the shoulder, tells it to sync,
but Linux may take it's pretty time in getting around to it.  Personally,
I've never seen it take more than a second after the sync call to write the
buffers, but it is technically a problem. (It's only a REAL problem if you're
shutting down, which is why you have programs that handle things for you).
	So, don't concern yourself with it.  Running sync is as good as you
will be able to get without hacking linux code and taking caching out
altogether, which I might mention again is not a good idea.  Caching speeds
things up a lot--try this excersize.  Boot any of two things that you haven't
run in a while--a good choice is netscape, since it takes forever to load.
The first one will grind for awhile before appearing; the next one appears
-instantly-.  That's caching, and it's nice.

4. Installation
	This code is about as portable as possible; any UNIX machine on the
planet should be able to compile and run this.  And if it doesn't compile
and run, guess what?  You accidently tried to compile it on a WinBloze box.
	ANYWAY...It's easy.  Type 'make'.  Then 'make install'.  Then
'make clean'.  Then run a command to update your path (rehash is what you
use for TCSH, I dunno about others) and type 'syncd'.  Note, make install
puts syncd in /usr/sbin/syncd.

5. Technical
	For anyone who cares, there's a system call called `sync()'.  It does
not actually fork off and execute the `sync' command; there is one fork, and
that is just to detach the process from the shell.  Cool, huh?  If you don't
understand this crap, you either 1) don't know C, or 2) haven't taken enough
operating systems courses and should either 1) Learn C or 2) take more
operating systems courses.  Or just not concern yourself, which is also
very advisable, since if you know this stuff you probably don't have a life.
I know I don't. :-)

6. Problems?  Questions?  Comments?
	Email me!  root@serpentine.dyn.ml.org. I'm also dying of curiosity
to see if anyone cares about this or uses it; go ahead and email, just say
hi, bring a little joy in my life.  And if you're female, please, please
offer to go out on a date with me.  That would make my life ;-)



Steve Conley, Head Coder, Serpentine Network Industries
root@serpentine.dyn.ml.org
