Hi, On 2023-04-10 18:55:26 -0700, Andres Freund wrote: > On 2023-04-10 19:27:27 +1200, Thomas Munro wrote: > > On Mon, Apr 10, 2023 at 2:57 PM Andres Freund <and...@anarazel.de> wrote: > > > Have you tried to write a reproducer for this that doesn't involve > > > postgres? > > > > I tried a bit. I'll try harder soon. > > > > > ... What kernel version did you repro > > > this on Thomas? > > > > Debian's 6.0.10-2 kernel (Debian 12 on a random laptop). Here's how I > > set up a test btrfs in case someone else wants a head start: > > > > truncate -s2G 2GB.img > > sudo losetup --show --find 2GB.img > > sudo mkfs -t btrfs /dev/loop0 # the device name shown by losetup > > sudo mkdir /mnt/tmp > > sudo mount /dev/loop0 /mnt/tmp > > sudo chown $(whoami) /mnt/tmp > > > > cd /mnt/tmp > > /path/to/initdb -D pgdata > > ... (see instructions further up for postgres command line + queries to run) > > I initially failed to repro the issue with these instructions. Turns out that > the problem does not happen if huge pages are in used - I'd configured huge > pages, so the default huge_pages=try succeeded. As soon as I disable > huge_pages explicitly, it reproduces. > > Another interesting bit is that if checksums are enabled, I also can't > reproduce the issue. Together with the huge_page issue, it does suggest that > this is somehow related to page faults. Which fits with the thread Andrea > referenced...
The last iteration of the fix that I could find is: https://lore.kernel.org/linux-btrfs/20230328051957.1161316-1-...@lst.de/T/#m1afdc3fe77e10a97302e7d80fed3efeaa297f0f7 And the fix has been merged into https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/log/?h=for-next I think that means it'll have to wait for 6.4 development to open (in a few weeks), and then will be merged into the stable branches from there. Greetings, Andres Freund