From: | Doug McNaught <doug(at)wireboard(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | bruc(at)acm(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: XFS File systems and PostgreSQL |
Date: | 2001-05-03 00:27:35 |
Message-ID: | m37kzzl1jc.fsf@belphigor.mcnaught.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, the irony is that a journaling file system is being used to have
> fast, reliable restore after crash bootup, but with no fsync, the db is
> probably hosed.
It just struck me--is it necessarily true that we get the big
performance hit?
On a non-data-journaling FS (like ext3), since WAL files are
preallocated (right?), a WAL sync shouldn't involve any metadata
updates. So we just write the WAL data to a (hopefully contiguous)
chunk of data blocks.
On an FS that journals data AND metadata, fsync() can return once the
updates are committed to the log--it doesn't have to wait until the
log is back-flushed (or whatever you call it) to the main filesystem.
The above is theoretical, and I don't know enough about Reiser or XFS
to know how they behave.
-Doug
--
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time... --Dylan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert E. Bruccoleri | 2001-05-03 00:49:36 | Re: XFS File systems and PostgreSQL |
Previous Message | Bruce Momjian | 2001-05-03 00:19:23 | Re: XFS File systems and PostgreSQL |