Greg wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>
> > Merlin,
> >
> > > I think the danger about SATA is that many SATA components are not
> > > server quality, so you have to be more careful about what you buy.
> For
> > > example, you can't just assume your SATA backplane has hot swap
lights
> > > (got bit by this one myself, heh).
> >
> > Yeah, that's my big problem with anything IDE. My personal
experience
> of
> > failure rates for IDE drives, for example, is about 1 out of 10
fails in
> > service before it's a year old; SCSI has been more like 1 out of 50.
>
> Um. I'm pretty sure the actual hardware is just the same stuff. It's
just
> the
> interface electronics that change.
>
> > Also, while I've seen benchmarks like Escalade's, my real-world
> experience has
> > been that the full bi-directional r/w of SCSI means that it takes 2
SATA
> > drives to equal one SCSI drive in a heavy r/w application.
However,
> ODSL is
> > all SCSI so I don't have any numbers to back that up.
>
> Do we know that these SATA/IDE controllers and drives don't "lie"
about
> fsync
> the way most IDE drives do? Does the controller just automatically
disable
> the
> write caching entirely?
>
> I don't recall, did someone have a program that tested the write
latency
> of a
> drive to test this?
>
> --
> greg
The Escalades, at least, work the way they are supposed to. The raid
controller supports write back/write through. Thus, you can leave fsync
on in pg with decent performance (not as good as fsync=off, though) and
count on the bbu to cover you in the event of a power failure. Our
internal testing here confirmed the controller and the disks sync when
you tell them to (namely escalade/raptor).
Merlin
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
