On Thu, Feb 5, 2026 at 7:59 AM Andres Freund <[email protected]> wrote: > > Hi, > > On 2024-12-20 11:39:42 -0500, Andres Freund wrote: > > On 2024-12-19 17:47:13 +1100, Michael Harris wrote: > > > This is a different system to those I previously provided logs from. > > > It is also running RHEL8 with a similar configuration to the other > > > system. > > > > Given it's a RHEL system, have you raised this as an issue with RH? They > > probably have somebody with actual XFS hacking experience on staff. > > > > RH's kernels are *heavily* patched, so it's possible the issue is actually > > RH > > specific. > > FWIW, I raised this on the #xfs irc channel. One ask they had was: > > │15:56:40 dchinner | andres: can you get a metadump of a filesystem that is > displaying these symptoms for us to analyse? > │15:57:54 dchinner | metadumps don't contain data, and metadata is > obfuscated so no filenames or attributes are exposed, either.
FWIW, I just learned yesterday that we went full circle on this: Redhat has published [1] "XFS fallocate(2) returning ENOSPC prematurely" several months ago. It references "commit 6773da870ab89123d1b513da63ed59e32a29cb77" titled "xfs: fix error returns from xfs_bmapi_write" , so folks just need to update to proper kernels. In addition we can do now: postgresql_discovering_linux_kernel_bugs++. Quick search also shows that e.g. linux-stable 6.1.x got it in 6.1.138 around May 2025, so probably all kernels released before are all affected. This pretty much matches the observation made earlier that it was mainly hit by people upgrading databases on the same host without updating OS/reinstalling hardware (re-using the older kernel). BTW: from our side we also have workaround patch (with GUC for this) solving 2nd problem and that is pending for inclusion in separate thread[2] -J. [1] - https://access.redhat.com/solutions/7129010 [2] - https://www.postgresql.org/message-id/flat/CAKZiRmyDR5d7jdKdhL6TNKMtcY0fAaS-OQ3Bk3ZVejLZMrTCQw%40mail.gmail.com#585ff2a71909c06a3c0d054d4f5a2383 by Thomas.
