Re: Fwd: Is the fsync() fake on FreeBSD6.1?

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