Message-ID: <4d25050c-2690-4683-bebf-7da5301cb44a@yandex.ru>
Date: Thu, 18 Jun 2026 23:33:20 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: AW: Size of /pgdata
To: "William Sescu (Suva)" <william.sescu@suva.ch>,
 Raj <rajeshkumar.dba09@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
 Pgsql-admin <pgsql-admin@lists.postgresql.org>
References: 
 <CAJk5Atb1v7=x-wsS-tL7Lxs7yXQy8Ng-GhXG+zzZ1gVAx=Xzjw@mail.gmail.com>
 <e55acd6eb1b237f1293b0150f60e1655a8778724.camel@cybertec.at>
 <CAJk5AtburOY2ugaH-6+8OHgOBwyyaq1V3LLozCAf57c5jtmR+w@mail.gmail.com>
 <db46ab37a8ca7bcae168ed45e73c4d68908993ab.camel@cybertec.at>
 <CAJk5AtZfFBqLfKyz7rAqJOXT0ZvEXna19wMn==YCin-PLUGiXw@mail.gmail.com>
 <3a2c4d549587beb3528f6ce09b3d4c448d32f8ee.camel@cybertec.at>
 <CAJk5AtZQ-4Wg0vnYLO5BJJntMG1oBEmvediAYQKXj0OL6MsOww@mail.gmail.com>
 <e988960a1d5dbf7b483c1374bce04351ff6f1dd3.camel@cybertec.at>
 <CAJk5AtarTco=DXJw8qDOe_CET5hUApb-aEJr5xL2pEAFgnsdNQ@mail.gmail.com>
 <ce3c4c54edfd1e5d451bc0605b71fd94f99215eb.camel@cybertec.at>
 <GV0P278MB0244DE5A2049D0A42E471445E8E42@GV0P278MB0244.CHEP278.PROD.OUTLOOK.COM>
 <CAJk5AtatQQ9npW-nffLXA9L-ivmyiEyvOse0XicbYZ53_-YATg@mail.gmail.com>
 <GV0P278MB0244AD72B327E57199FDD07CE8E32@GV0P278MB0244.CHEP278.PROD.OUTLOOK.COM>
Content-Language: en-US, ru
From: Aleksey M Boltenkov <padrebolt@yandex.ru>
In-Reply-To: 
 <GV0P278MB0244AD72B327E57199FDD07CE8E32@GV0P278MB0244.CHEP278.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/4d25050c-2690-4683-bebf-7da5301cb44a%40yandex.ru>
Precedence: bulk

On 6/18/26 07:59, William Sescu (Suva) wrote:
> By setting XFS allocsize, you switch off the dynamic behavior, and it 
> becomes more predictable.
> 
> Another fix might be a switch to a different filesystem. E.g. ext4
> 
> While this XFS feature is a quite old one, I have seen it the first time 
> kicking in quite heavily only on Red Hat 9, with PostgreSQL 18 and
> 
> only on the standby. Some times double the size for some files.
> 
> *Von:*Raj <rajeshkumar.dba09@gmail.com>
> *Gesendet:* Mittwoch, 17. Juni 2026 20:46
> *An:* Sescu William (SW0) <william.sescu@suva.ch>
> *Cc:* Laurenz Albe <laurenz.albe@cybertec.at>; Pgsql-admin <pgsql- 
> admin@lists.postgresql.org>
> *Betreff:* Re: Size of /pgdata
> 
> Yes, this is what I have been asking. I also mentioned/asked earlier 
> whether it's Abt XFS file system.
> 
> I checked bitmaps and under flags I could find 'unwritten preallocated 
> extent'. --apparent-size says shows correct size.
> 
> Is the fix - setting up allocsize?
> 
> On Wed, 17 Jun 2026, 19:29 William Sescu (Suva), <william.sescu@suva.ch 
> <mailto:william.sescu@suva.ch>> wrote:
> 
>     In case you are using XFS, this might be related to the "Speculative
>     preallocation" feature.
>     We saw the same behavior on Redhat 9, with PostgreSQL 18 and XFS.
> 
>     https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/
>     html/storage_administration_guide/migrating-ext4-xfs <https://
>     docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/
>     storage_administration_guide/migrating-ext4-xfs>
> 
>     Speculative preallocation
> 
>     XFS uses speculative preallocation to allocate blocks past EOF as
>     files are written. This avoids file fragmentation due to concurrent
>     streaming write workloads on NFS servers. By default, this
>     preallocation increases with the size of the file and will be
>     apparent in "du" output. If a file with speculative preallocation is
>     not dirtied for five minutes the preallocation will be discarded. If
>     the inode is cycled out of cache before that time, then the
>     preallocation will be discarded when the inode is reclaimed.
>     If premature ENOSPC problems are seen due to speculative
>     preallocation, a fixed preallocation amount may be specified with
>     the -o allocsize=amount mount option.
> 
>     See also "man xfs"
> 
>     allocsize=size
>     Sets  the  buffered  I/O end-of-file preallocation size when doing
>     delayed allocation writeout. Valid values for this option are page
>     size (typically 4KiB) through to
>     1GiB, inclusive, in power-of-2 increments.
> 
>     The default behavior is for dynamic end-of-file preallocation size,
>     which uses a set of heuristics to optimise the preallocation size
>     based on the current  allocation
>     patterns within the file and the access patterns to the file.
>     Specifying a fixed allocsize value turns off the dynamic behavior.
> 
> 
>     Cheers
>     William
> 
> 
>     -----Ursprüngliche Nachricht-----
>     Von: Laurenz Albe <laurenz.albe@cybertec.at
>     <mailto:laurenz.albe@cybertec.at>>
>     Gesendet: Mittwoch, 17. Juni 2026 13:34
>     An: Raj <rajeshkumar.dba09@gmail.com
>     <mailto:rajeshkumar.dba09@gmail.com>>
>     Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org <mailto:pgsql-
>     admin@lists.postgresql.org>>
>     Betreff: Re: Size of /pgdata
> 
> 
> 
>        ACHTUNG: Diese Nachricht kommt von extern. Seien Sie kritisch
>     beim Öffnen von Links und Anhängen.
> 
> 
> 
> 
>     On Wed, 2026-06-17 at 11:47 +0530, Raj wrote:
>      > The file count is same between them..but the file size varies.
>      >
>      > For example, assume node1 has issue and node2 is clean.
>      >
>      > 1. On both nodes file count is 76
>      > 2. File size varies for some of them
>      >
>      > Each files are either 1GB or 2GB and some or them are 1.2gb or
>     1.5gb or between 1-2gb ....by looking at files..
>      >  In the problematic node, some of the 1gb files in node2  shows
>     2GB in node1...and also file size differences. making the difference.
> 
>     That is highly suspicious.
> 
>     What do you get if you run
> 
>        SHOW segment_size;
> 
>     Unless you built PostgreSQL yourself after changing the segment
>     size, it should be 1GB.  But then it would be impossible for some
>     segment to be bigger than 1GB.
> 
>     Are you using some weird file system that reports file sizes wrongly?
> 
>     What does "ls -l" on one of these big files show?
> 
>     Yours,
>     Laurenz Albe
> 
> 
> 
>     ________________________________
> 
>     Disclaimer:
> 
>     Diese Nachricht und ihr eventuell angehängte Dateien sind nur für
>     den Adressaten bestimmt. Sie kann vertrauliche oder gesetzlich
>     geschützte Daten oder Informationen beinhalten. Falls Sie diese
>     Nachricht irrtümlich erreicht hat, bitten wir Sie höflich, diese
>     unter Ausschluss jeglicher Reproduktion zu löschen und die
>     absendende Person zu benachrichtigen. Danke für Ihre Hilfe.
> 
>     This message and any attached files are for the sole use of the
>     recipient named above. It may contain confidential or legally
>     protected data or information. If you have received this message in
>     error, please delete it without making any copies whatsoever and
>     notify the sender. Thank you for your assistance.
> 

R U joking? Preallocation is around kilobytes, some time megabytes.