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
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 |