On 2018-02-20 01:56:17 +0000, Tsunakawa, Takayuki wrote:
> Disabling the filesystem barrier is a valid tuning method as the PG manual 
> says:

I don't think it says that:

> https://www.postgresql.org/docs/devel/static/wal-reliability.html
> [Excerpt]
> Recent SATA drives (those following ATAPI-6 or later) offer a drive cache 
> flush command (FLUSH CACHE EXT), while SCSI drives have long supported a 
> similar command SYNCHRONIZE CACHE. These commands are not directly accessible 
> to PostgreSQL, but some file systems (e.g., ZFS, ext4) can use them to flush 
> data to the platters on write-back-enabled drives. Unfortunately, such file 
> systems behave suboptimally when combined with battery-backup unit (BBU) disk 
> controllers. In such setups, the synchronize command forces all data from the 
> controller cache to the disks, eliminating much of the benefit of the BBU. 
> You can run the pg_test_fsync program to see if you are affected. If you are 
> affected, the performance benefits of the BBU can be regained by turning off 
> write barriers in the file system or reconfiguring the disk controller, if 
> that is an option. If write barriers are turned off, make sure the battery 
> remains functional; a faulty battery can potentially lead to data loss. 
> Hopefully file system and disk controller designers will eventually address 
> this suboptimal behavior.

Note it's only valid if running with a BBU. In which case the
performance measurements you're doing aren't particularly meaningful
anyway, as you'd test BBU performance rather than disk performance.


Andres Freund

Reply via email to