* Tom Lane <tgl@sss.pgh.pa.us> [081002 11:40]:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> > Just to see where to go from here... I want to make sure the options
> > I've seen in this thread are laid out clearly:
>
> > 1. Hold an exclusive lock on the buffer during the call to smgrwrite
> > OR
> > 2. Doublebuffer the write
> > OR
> > 3. Do some crufty magic to ignore hint-bit updates
>
> Right, I think everyone agrees now that #2 seems like the most
> preferable option for writing the checksum. However, that still
> leaves us lacking a solution for torn pages during a write that
> follows a hint bit update. We may end up with some "crufty
> magic" anyway for dealing with that.
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?
#define write(fd, buf, count) buffer_crc_write(fd, buf, count)
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.
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...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
