From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: fsync = true beneficial on ext3? |
Date: | 2004-02-08 20:44:42 |
Message-ID: | 200402081344.42846.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sunday February 8 2004 12:02, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > If we write something without sync'ing, presumably it's immediately
> > journaled?
>
> I was under the impression that ext3 journals only filesystem metadata,
> not the contents of files.
Ah, didn't know how that worked. So I gather there is really no
kernel-level substitute for fsync = true when it comes to guaranteeing data
is flushed to disk at commit time, I guess?
In linux, does pgsql's fsync call at commit time obviate the need for
bdflush to do any flushing for that particular data? I'm wondering if
there are bdflush adjustments to be made to improve disk write efficiency
given we can count on fsync = true to guarantee that .
Also, with fsync = true and wal using fdatasync, and assuming all is on the
same disk (which I know is not optimal), is there a particular ext3 mode
(data=writeback?) that gives better performance while maintaining best
recoverability?
From | Date | Subject | |
---|---|---|---|
Next Message | W. van den Akker | 2004-02-08 20:53:12 | Re: Extract transaction logging |
Previous Message | Christopher Browne | 2004-02-08 20:21:36 | Re: Fwd: Favorite DB poll on ORA |