Re: Simplifying wal_sync_method

On 2005-08-09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrew - Supernews <andrew+nonews(at)supernews(dot)com> writes:
>> On 2005-08-09, "Magnus Hagander" <mha(at)sollentuna(dot)net> wrote:
>>> ... or iDE disks with write cache enabled. I've certainly seen more than
>>> what I'd call 1% (though I haven't studied it to be sure) that's because
>>> of write-cached disks...
>
>> Every SCSI disk I've looked at recently has had write cache enabled by
>> default, fwiw.
>
> On SCSI, write cacheing is default because the protocol is actually
> designed to support it: the drive can take the data, and then take some
> more, without giving the impression that the write has been done.

Wrong. Write caching as controlled by the WCE parameter on mode page 8
for direct-access devices does in fact report the write operation as
complete before the bits are on the disk. The protocol supplies a number
of additional commands to flush the cache, etc., for which you'll have
to consult the specs.

The reason it's not so much of a performance killer to turn it off is that
tag-queueing (which is what you are referring to) provides for some
optimization of concurrent requests even with the cache off.

> If a SCSI drive reports write complete when it hasn't actually put the
> bits on the platter yet, then it's simply broken.

I guess you haven't read the spec much, then.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services