xfs
[Top] [All Lists]

Re: Problems with filesizes on different Kernels

To: Bernhard Schrader <bernhard.schrader@xxxxxxxxxxxx>
Subject: Re: Problems with filesizes on different Kernels
From: Matthias Schniedermeyer <ms@xxxxxxx>
Date: Fri, 17 Feb 2012 13:33:35 +0100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4F3E3F5A.9000202@xxxxxxxxxxxx>
References: <4F3E3F5A.9000202@xxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On 17.02.2012 12:51, Bernhard Schrader wrote:
> Hi all,
> 
> we just discovered a problem, which I think is related to XFS. Well,
> I will try to explain.
> 
> The environment i am working with are around 300 Postgres databases
> in separated VM's. All are running with XFS. Differences are just in
> kernel versions.
> - 2.6.18
> - 2.6.39
> - 3.1.4
> 
> Some days ago i discovered that the file nodes of my postgresql
> tables have strange sizes. They are located in
> /var/lib/postgresql/9.0/main/base/[databaseid]/
> If I execute the following commands i get results like this:
> 
> Command: du -sh | tr "\n" " "; du --apparent-size -h
> Result: 6.6G  . 5.7G  .

Since a few kernel-version XFS does speculative preallocations, which is 
primarily a measure to prevent fragmentation.

The preallocations should go away when you drop the caches.

sync
echo 3 > /proc/sys/vm/drop_caches

XFS can be prevented to do that with the mount-option "allocsize". 
Personally i use "allocsize=64k", since i first encountered that 
behaviour, my workload primarily consists of single-thread writing which 
doesn't benefit from this preallocation.
Your workload OTOH may benefit as it should prevent/lower the 
fragmentation of the database files.






Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

<Prev in Thread] Current Thread [Next in Thread>