solid-state drives (SSD) also have volatile write-back caches.
  </para>

  <para>
   These caches can typically be disabled; however, the method for doing
   this varies by operating system and drive type:
  </para>

  <itemizedlist>
    <listitem>
      <para>
        On <productname>Linux</productname>, IDE and SATA drives can be queried using
        <command>hdparm -I</command>; write caching is enabled if there is
        a <literal>*</literal> next to <literal>Write cache</literal>.  <command>hdparm -W 0</command>
        can be used to turn off write caching.  SCSI drives can be queried
        using <ulink url="http://sg.danny.cz/sg/sdparm.html"><application>sdparm</application></ulink>.
        Use <command>sdparm --get=WCE</command> to check
        whether the write cache is enabled and <command>sdparm --clear=WCE</command>
        to disable it.
      </para>
    </listitem>

    <listitem>
      <para>
        On <productname>FreeBSD</productname>, IDE drives can be queried using
        <command>camcontrol identify</command> and write caching turned off using
        <literal>hw.ata.wc=0</literal> in <filename>/boot/loader.conf</filename>;
        SCSI drives can be queried using <command>camcontrol identify</command>,
        and the write cache both queried and changed using
        <command>sdparm</command> when available.
      </para>
    </listitem>

    <listitem>
      <para>
        On <productname>Solaris</productname>, the disk write cache is controlled by
        <command>format -e</command>.
        (The Solaris <acronym>ZFS</acronym> file system is safe with disk write-cache
        enabled because it issues its own disk cache flush commands.)
      </para>
    </listitem>

    <listitem>
      <para>
        On <productname>Windows</productname>, if <varname>wal_sync_method</varname> is
        <literal>open_datasync</literal> (the default), write caching can be disabled
        by unchecking <literal>My Computer\Open\<replaceable>disk drive</replaceable>\Properties\Hardware\Properties\Policies\Enable write caching on the disk</literal>.
        Alternatively, set <varname>wal_sync_method</varname> to
        <literal>fdatasync</literal> (NTFS only) or <literal>fsync</literal>,
        which prevent write caching.
      </para>
    </listitem>

    <listitem>
      <para>
        On <productname>macOS</productname>, write caching can be prevented by
        setting <varname>wal_sync_method</varname> to <literal>fsync_writethrough</literal>.
      </para>
    </listitem>
  </itemizedlist>

  <para>
   Recent SATA drives (those following <acronym>ATAPI-6</acronym> or later)
   offer a drive cache flush command (<command>FLUSH CACHE EXT</command>),
   while SCSI drives have long supported a similar command
   <command>SYNCHRONIZE CACHE</command>.  These commands are not directly
   accessible to <productname>PostgreSQL</productname>, but some file systems
   (e.g., <acronym>ZFS</acronym>, <acronym>ext4</acronym>) 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
   (<acronym>BBU</acronym>) 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
   <xref linkend="pgtestfsync"/> 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.
  </para>

  <para>
   When the operating system sends a write request to the storage hardware,
   there is little it can