Andrew - Supernews wrote: > > Whether the underlying device lies about the write completion is another > matter. All current SCSI disks have WCE enabled by default, which means > that they will lie about write completion if FUA was not set in the > request, which FreeBSD never sets. (It's not possible to get correct > results by having fsync() somehow selectively set FUA, because that would > leave previously-completed requests in the cache.) > > WCE can be disabled on either a temporary or permanent basis by changing > the appropriate modepage. It's possible that Linux does this automatically, > or sets FUA on all writes, though that would surprise me considerably; > however I disclaim any knowledge of Linux internals.
The Linux SATA driver author Jeff Garzik suggests [note 1] that "The ability of a filesystem or fsync(2) to cause a [FLUSH|SYNC] CACHE command to be generated has only been present in the most recent [as of mid 2005] 2.6.x kernels. See the "write barrier" stuff that people have been discussing. "Furthermore, read-after-write implies nothing at all. The only way to you can be assured that your data has "hit the platter" is (1) issuing [FLUSH|SYNC] CACHE, or (2) using FUA-style disk commands It sounds like your test (or reasoning) is invalid. " Before those min-2005 2.6.x kernels apparently fsync on linux didn't really try to flush caches even when drives supported it (which apparently most actually do if the requests are actually sent). [note 1] http://lkml.org/lkml/2005/5/15/82 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
