Re: Block-level CRC checks

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Aidan Van Dyk" <aidan(at)highrise(dot)ca>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Brian Hurt" <bhurt(at)janestcapital(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 16:43:05
Message-ID: 36e682920810020943n52c7bb1fq285b956a8c6973d4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 2, 2008 at 12:05 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> How does your current "write" strategy handle this situation. I mean,
> how do you currently guarnetee that between when you call write() and
> the kernel copies the buffer internally, no hint-bit are updated?

Working on the exact double-buffering technique now.

> #define write(fd, buf, count) buffer_crc_write(fd, buf, count)

I certainly wouldn't interpose the write() call itself; that's just
asking for trouble.

> whatever protection you have on the regular write is sufficient. The
> time of the protection will need to start before the "buffer" period
> instead of just the write, (and maybe not the write syscall anymore) but
> with CPU caches and speed, the buffer period should be <= the time of
> the write() syscall... Your fsync is your "on disk guarentee", not the
> write, and that won't change.

Agreed.

> But I thought you didn't really care about hint-bit updates, even in the
> current strategy... but I'm fully ignorant about the code, sorry...

The current implementation does not take it into account.

--
Jonah H. Harris, Senior DBA
myYearbook.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2008-10-02 16:51:01 Re: Block-level CRC checks
Previous Message Joshua Drake 2008-10-02 16:13:38 Re: Block-level CRC checks