From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | andrew(at)supernews(dot)com |
Subject: | Re: Fwd: Is the fsync() fake on FreeBSD6.1? |
Date: | 2006-09-24 12:26:06 |
Message-ID: | 4516795E.4090603@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2006-09-24 12:40:44 | Re: PostgreSQL 8.2beta1 w/ VALUES |
Previous Message | Dave Page | 2006-09-24 10:51:49 | Re: Buildfarm alarms |