Re: Simplifying wal_sync_method

Поиск
Список
Период
Сортировка
От Andrew - Supernews
Тема Re: Simplifying wal_sync_method
Дата
Msg-id slrndfikuc.bj3.andrew+nonews@trinity.supernews.net
обсуждение исходный текст
Ответ на Re: Simplifying wal_sync_method  ("Magnus Hagander" <mha@sollentuna.net>)
Ответы Re: Simplifying wal_sync_method  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2005-08-09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>> On 2005-08-09, "Magnus Hagander" <mha@sollentuna.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Solving the OID-collision problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Simplifying wal_sync_method