Re: FileFallocate misbehaving on XFS

Hi,

On 2024-12-10 12:36:33 +0100, Jakub Wartak wrote:
> On Tue, Dec 10, 2024 at 7:34 AM Michael Harris <harmic(at)gmail(dot)com> wrote:
> 1. Well it doesn't look like XFS AG fragmentation to me (we had a customer
> with a huge number of AGs with small space in them) reporting such errors
> after upgrading to 16, but not for earlier versions (somehow
> posix_fallocate() had to be the culprit).

Given the workload expires old partitions, I'm not sure we conclude a whole
lot from the current state :/

> 2.
>
> > # xfs_info /dev/mapper/ippvg-ipplv
> > meta-data=/dev/mapper/ippvg-ipplv isize=512 agcount=4,
> agsize=262471424 blks
> > = sectsz=512 attr=2, projid32bit=1
> > = crc=1 finobt=0, sparse=0, rmapbt=0
> > = reflink=0 bigtime=0 inobtcount=0
> nrext64=0
>
> Yay, reflink=0, that's pretty old fs ?!

I think that only started to default to on more recently (2019, plus time to
percolate into RHEL). The more curious cases is finobt=0 (turned on by default
since 2015) and to a lesser degree sparse=0 (turned on by default since 2018).

> > ERROR: could not extend file
> "pg_tblspc/16401/PG_16_202307071/17643/1249.1" with FileFallocate(): No
> space left on device
>
> 2. This indicates it was allocating 1GB for such a table (".1"), on
> tablespace that was created more than a year ago. Could you get us maybe
> those below commands too? (or from any other directory exhibiting such
> errors)

The date in the directory is the catversion of the server, which is just
determined by the major version being used, not the creation time of the
tablespace.

andres(at)awork3:~/src/postgresql$ git grep CATALOG_VERSION_NO upstream/REL_16_STABLE src/include/catalog/catversion.h
upstream/REL_16_STABLE:src/include/catalog/catversion.h:#define CATALOG_VERSION_NO 202307071

Greetings,

Andres Freund