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] CACHEcommand to be generated has only been present in
themost recent [as ofmid 2005] 2.6.x kernels. See the "write barrier" stuff that peoplehave been discussing.
"Furthermore,read-after-write implies nothingat all. The only way to you can be assured that your data has "hitthe
platter"is (1) issuing [FLUSH|SYNC] CACHE, or (2) using FUA-style disk commandsIt 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