Re: Direct I/O - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Direct I/O
Date
Msg-id CA+hUKG+F8HgEoimV-42bFXJbsd4yeQ6DF1VEc2LZ4bB-OfcV6Q@mail.gmail.com
Whole thread Raw
In response to Re: Direct I/O  (Andres Freund <andres@anarazel.de>)
Responses Re: Direct I/O  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Sun, Apr 9, 2023 at 2:18 PM Andres Freund <andres@anarazel.de> wrote:
> On 2023-04-09 13:55:33 +1200, Thomas Munro wrote:
> > I think that particular thing might relate to modifications of the
> > user buffer while a write is in progress (breaking btrfs's internal
> > checksums).  I don't think we should ever do that ourselves (not least
> > because it'd break our own checksums).  We lock the page during the
> > write so no one can do that, and then we sleep in a synchronous
> > syscall.
>
> Oh, but we actually *do* modify pages while IO is going on. I wonder if you
> hit the jack pot here. The content lock doesn't prevent hint bit
> writes. That's why we copy the page to temporary memory when computing
> checksums.

More like the jackpot hit me.

Woo, I can now reproduce this locally on a loop filesystem.
Previously I had missed a step, the parallel worker seems to be
necessary.  More soon.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Direct I/O
Next
From: "Gregory Stark (as CFM)"
Date:
Subject: Re: Use fadvise in wal replay