unexplained cores after compiles

[was-John McMillan]

Asbestos on:  The following are opinions ...

SYNC is fine for its intended use: to force all Deferred-Write blocks out
	through a healthy I/O subsystem.

In fact, it is far more reliable/reasonable than the netnews articles
mentioning it often are. ;^)

In article <7724 at chinet.chi.il.us> ignatz at chinet.chi.il.us (Dave Ihnat) writes:
>...
>Nothing major, but I do want to quell any hopes that people may have that this
>is the answer to a reliable Unix database.

	Lacking any definition of "a reliable UNIX(rg) database" on
	your part, this is irrefutable.  (I am NOT requesting such a
	definition -- just pointing out you've taken the easy road.)

>						 Sync(2) doesn't even really
>guarantee that the flush is started by the time you get control back from the
>call--only that it's been scheduled.

	Perhaps a definition of "started" was in order.  By the time the
	SYNC(2) call returns, either your call has queued all the writes
	to the disk, or another process is amidst doing this -- but is
	momentarily blocked by a resource lock of some sort.

	There is no "scheduled" process which has responsibility to
	complete YOUR requested sync at an indeterminate future time.
	The indeterminate feature is whether some one else is ALREADY
	doing it, or the length of time it will take to flush out the
	scheduled writes -- typically < NBUF * .02sec.

>					 (Thus the apocryphal "sync;sync;sync"
>before rebooting Unix systems.)

	As I was told, about 15 years ago, the reason for multiple
	SYNCs was: even YOU won't make a typographical error
	3 times in a row.  Made sense.  Still does.  WHAT does your
	"Thus" mean?  I don't see any tie between the previous assertion
	and the parenthetic one.  And the parenthetic one strikes me as
	irrelevant to the issue of databases.

	(Anyone who types "sync;sync;sync;reboot" doesn't know what
	they're doing: The disk must be allowed to become quiescent
	before any reboot.  All dismountable file systems should
	be dismounted before reboots: this guarantees they are flushed,
	and that the databases are at least as consistent as their
	designers. 8-} )
	
>				 This is why some vendors have added 'reliable
>writes' for database applications, guaranteeing that when you return the data
>is actually out on disk and not languishing in some dirty buffer.

	Sounds so seedy and degenerate, I kinda like it !-)

>									 This
>behavior, incidentally, was the "reason" that Unix would "never" make it in
>the business world that needs databases, since you could never guarantee the
>consistency of your view of the database with that actually recorded on disk.

	The key words are DROPPED here: "... AFTER A SYSTEM CRASH".

	There is NO defect in the BIO subsystem -- at least none
	identified above -- in a running system.  But... there are
	several features involving the sequencing of WRITES that
	can "encourage" inconsistent databases.  For instance, the
	most heavily accessed blocks are the "last" to be flushed
	by buffer requests: this can mean your most central control
	blocks are the most vulnerable in a crash.  In another
	direction, SYNC's typically write in a head-movement
	optimized order [ELEVATOR algorithms] -- which does not
	represent any file-access sequencing and can effect
	inconsistencies.
	
>The success and continued expansion of such packages as Informix, Oracle, etc.,
>of course, show that this wasn't nearly the huge problem that was anticipated.

	Suppose so.  I DO wish the BIO and crash-recovery would be
	extended to better support everyone, including DB requirements: 
	In those Olden, Golden Daze of UNIX there were many crashes
	where you couldn't trust the consistency of ANYTHING --
	including the cached buffers.  Nowadays, crashes seem to involve
	exotic corners which usually have little bearing on the BIO
	-- "WOOPS, there went FOOPlan again", or "OK, 27000 Widgets DOES
	bring my Cray-PC down".  What would it take to record enough
	of the mount/BIO info to permit the flushing of those olde
	buffers during the primordeal [sick] BOOT phases?

Back into the cave...

jc mcmillan	-- att!mtunb!jcm	-- speaking only for himself, not THEM