Curt Sampson wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> > Actually, this brings up a different point. We use 8k blocks now
> > because at the time PostgreSQL was developed, it used BSD file systems,
> > and those prefer 8k blocks, and there was some concept that an 8k write
> > was atomic, though with 512 byte disk blocks, that was incorrect. (We
> > knew that at the time too, but we didn't have any options, so we just
> > hoped.)
>
> MS SQL Server has an interesting way of dealing with this. They have a
> "torn" bit in each 512-byte chunk of a page, and this bit is set the
> same for each chunk. When they are about to write out a page, they first
> flip all of the torn bits and then do the write. If the write does not
> complete due to a system crash or whatever, this can be detected later
> because the torn bits won't match across the entire page.
I was wondering, how does knowing the block is corrupt help MS SQL?
Right now, we write changed pages to WAL, then later write them to disk.
I have always been looking for a way to prevent these WAL writes. The
512-byte bit seems interesting, but how does it help?
And how does the bit help them with partial block writes? Is the bit at
the end of the block? Is that reliable?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
