From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Doug McNaught <doug(at)wireboard(dot)com> |
Cc: | bruc(at)acm(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: XFS File systems and PostgreSQL |
Date: | 2001-05-03 00:54:21 |
Message-ID: | 200105030054.f430sL904154@candle.pha.pa.us |
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.
Theoretically, yes, all these log-based file system just log metadata
changes, not user data, so it should not affect it. I just don't know
how well the fsync's are implemented on these things.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-03 01:32:25 | Re: Collation order for btree-indexable datatypes |
Previous Message | Robert E. Bruccoleri | 2001-05-03 00:49:36 | Re: XFS File systems and PostgreSQL |