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
|
Список | 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 по дате отправления: