Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: DCRON
Message-ID: <8812292136.AA14633@postgres.Berkeley.EDU>
Date: 29 Dec 88 21:36:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 24

:>	No No, even with only 5 buffers, the two that are needed for the
:>Lock/Examine are most likely cached after the first try.  And, of 
:>course, when it *does* access the disk it's only to read a sector or two...
:>it only writes (updates the log) when there is actually something to do, and
:>unless you have a * * * * * * entry which is run every minute, this doesn't
:>happen often.
:
:I don't know about your setup and operating methods, but I use my machine a
:lot. I'd be willing to bet that after starting cron in a startup-sequence, I'd
:lose that cached data in a matter of minutes, due to all the other activity.

	<sigh>. .. People are still not thinking!  If you use your disk 
enough that the cached data is lost, at the time dcron comes around and
does the lock/examine you'll get a disk access and it will be cached again.
Since you are using your disk a lot anyway this extra access will not be
noticed.

	On the otherhand, if you are not using your disk at all the cached
data is not lost and thus dcron makes no disk accesses.

	Now, before we continue this argument why doesn't somebody *TEST*
the perceived problem using dcron, ok?

				-Matt