On Tue, 2 Dec 2003, Alex Satrapa wrote:
> Marco Colombo wrote:
> > On Fri, 28 Nov 2003, Alex Satrapa wrote:
> >> From the BSD-bigot's point of view, this is equivalent to the end of
> >>the world as we know it.
> >
> > From anyone's point of view, loosing track of a committed transaction
> > (and an accepted message is just that) is the end of the world.
>
> When hardware fails, you'd be mad to trust the data stored on the
> hardware. You can't be sure that the data that's actually on disk is
> what was supposed to be there, the whole of what's supposed to be there,
> and nothing but what's supposed to be there. You just can't. This
> emphasis that some people have on "committing writes to disk" is misplaced.
>
> If the data is really that important, you'd be sending it to three
> places at once (one or three, not two - ask any sailor about clocks) -
> async or not.
Sure, but we were discussing a 'pull the plug' scenario, not HW failures.
Only RAID (which is a way of sending data to different places)
saves you from a disk failure (if it can be _detected_!), and nothing
from a CPU/RAM failure, on a conventional PC (but a second PC, if you're
lucky). The original problem was ext2 loosing _only_ one message after
reboot when someone pulls the plug. The real problem is not the disk, it's
the application returning "OK, COMMITTED" to the other side (which may
be a SMTP client or a PostgreSQL client). IDE tricks these applications
in returning OK _before_ the data hits safe storage (platters). The FS
may play a role too, expecially for those applications that use fsync()
on a file to sync directory data too. On many journalled FS, fsync()
triggers a (global) journal write (which sometimes can be a performance
killer), so, as a side effect, a sync of directory data too.
AFAIK, ext2 is safe to use with PostgreSQL, since commits do not involve
any directory operation (if so, I hope PostgreSQL does a fsync() on the
involved directory too). With heavy transaction loads, I guess it will
outperform journalled filesystems, w/o _any_ loss in data safety. I have
no data to back up such a statement, though.
[ ok on the SCSI async behavior ]
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it