unexplained cores after compiles

[Dave Ihnat]

In article <610 at icus.islp.ny.us> lenny at icus.islp.ny.us (Lenny Tropiano) writes:
>The disadvantages to delayed write is that the user issuing the "write" system
>call is never sure when the data finally is written to the disk/media.
>Issuing a "sync" system call or using the "sync" command will assure that
>all dirty buffers are written to disk.
>	...
>It's very rare.  I would have trouble producing the error.  I had to stick
>"sync" system calls into my B-tree routines at work at strategic points to
>assure that the data is written out to the disk, hopefully not destroying
>the performance of the B-tree routines.

Nothing major, but I do want to quell any hopes that people may have that this
is the answer to a reliable Unix database.  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.  (Thus the apocryphal "sync;sync;sync"
before rebooting Unix systems.)  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.  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 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.