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