Re: XFS File systems and PostgreSQL

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

In response to

Browse pgsql-hackers by date

  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