Re: Recomended FS

Really solid microcode actually reads the sectors
just written and confirms the write at the hardware level
by comparing it with what is in the controller memory.
It then returns with a successfull confirmation or an error
if differences were detected.

Any data storage device controller, disk, memory stick, whatever
that does not follow this fundamental common sense protocol is
not reliable and should not be used, period!

Perhaps the IDE designers have folded to management pressure
and tried to make their drives "seem" faster by not taking
the time to actually confirm the write at the hardware level.
I don't know, but it looks like this may be a possiblity.

Lynn

Quoting "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com>:

> On Sat, 25 Oct 2003, James Moe wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sun, 26 Oct 2003 16:24:17 +1300, Mark Kirkwood wrote:
> >
> > >I would conclude that it not *always* the case that power failure
> > >renders the database unuseable.
> > >
> > >I have just noticed a similar posting from Scott were he finds the
> cache
> > >enabled case has a dead database after power failure.
> > >
> > Other posts have noted that SCSI never fails under this condition.
> Apparently SCSI
> > drives sense an impending power loss and flush the cache before power
> completely
> > disappears. Speed *and* reliability. Hm.
>
> Actually, it would appear that the SCSI drives simply don't lie about
> fsync. I.e. when they tell the OS that they wrote the data, they wrote
>
> the data. Some of them may have caching flushing with lying about fsync
>
> built in, but the performance looks more like just good fsyncing to me.
>
> It's all a guess without examining the microcode though... :-)
>
> > Of course, anyone serious about a server would have it backed up
> with a UPS and
> > appropriate software to shut the system down during an extended power
> outage. This just
> > leaves people tripping over the power cords or maliciously pulling the
> plugs.
>
> Or a CPU frying, or a power supply dying, or a motherboard failure, or a
>
> kernel panic, or any number of other possibilities. Admittedly, the
> first
> line of defense is always good backups, but it's nice knowing that if
> one
> of my CPUs fry, I can pull it, put in the terminator / replacement, and
> my
> whole machine will likely come back up.
>
> But anyone serious about a server will also likely be running on SCSI as
>
> well as on a UPS. We use a hosting center with 3 UPS and a Diesel
> generator, and we still managed to lose power about a year ago when one
>
> UPS went haywire, browned out the circuits of the other two, and the
> diesel generator's switch burnt out. Millions of dollars worth of UPS /
>
> high reliability equipment, and a $50 switch brought it all down.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>