Re: fsync or fdatasync

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Gaetano Mendola <mendola(at)bigfoot(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: fsync or fdatasync
Date: 2002-09-10 15:40:24
Message-ID: 200209101540.g8AFeOo21086@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


The original poster was wrong about the default.

We use fdatasync where available, and fsync when it is not. We also use
O_SYNC on open if it is available.

---------------------------------------------------------------------------

Gaetano Mendola wrote:
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
> news:11753(dot)1031590251(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> > "Gaetano Mendola" <mendola(at)bigfoot(dot)com> writes:
> > > apparently the default value for wal_sync_method is fsync,
> > > and apparently the best method is fdatasync.
> >
> > Best on what platform, and according to what evidence?
>
> Well, the man say ( Linux ):
>
>
> fdatasync flushes all data buffers of a file to disk (before the system call
> returns). It resembles fsync but is
> not required to update the metadata such as access time.
>
> Applications that access databases or log files often write a tiny
> data fragment (e.g., one line in a log file)
> and then call fsync immediately in order to ensure that the
> written data is physically stored on the harddisk.
> Unfortunately, fsync will always initiate two write operations: one
> for the newly written data and another one in
> order to update the modification time stored in the inode. If the
> modification time is not a part of the transac
> tion concept fdatasync can be used to avoid unnecessary inode disk
> write operations.
>
>
> So, what is wrong here ? Seems clear that one write is better than two.
>
> Ciao
> Gaetano
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jean-Arthur Silve 2002-09-10 16:07:50 Vacuum analyze infos
Previous Message Tom Lane 2002-09-10 15:02:53 Re: 7.2.2 upgrade, pg_dumpall / reload problem