xfs
[Top] [All Lists]

Re: [FAQ] XFS speculative preallocation

To: Dave Chinner <david@xxxxxxxxxxxxx>, Florian Weimer <fw@xxxxxxxxxxxxx>
Subject: Re: [FAQ] XFS speculative preallocation
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 21 Mar 2014 18:13:30 -0500
Cc: Brian Foster <bfoster@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140321231032.GC1389@dastard>
References: <20140321162920.GA3087@xxxxxxxxxxxxxx> <87eh1vuxam.fsf@xxxxxxxxxxxxxxxxx> <20140321231032.GC1389@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
On 3/21/14, 6:10 PM, Dave Chinner wrote:
> On Fri, Mar 21, 2014 at 09:11:29PM +0100, Florian Weimer wrote:
>> * Brian Foster:
>>
>>> Although speculative preallocation can lead to reports of excess space
>>> usage, the preallocated space is not permanent unless explicitly made so
>>> via fallocate or a similar interface.
>>
>> How does an explicit allocation with posix_fallocate interact with
>> speculative preallocation?  Does it disable it?
> 
> fallocate is permanent preallocation using unwritten extents.
> Speculative preallocation is an extension of delayed allocation that
> is done when extending the file and the EOF falls into a hole. If
> there is unwritten extents beyond EOF, speulative preallocation is
> not performed.
> 
>> I see rather dramatic fragmentation of the systemd journal when it is
>> stored on XFS, and it calls posix_fallocate before writing data to the
>> file.
> 
> There's your problem - systemd is preventing delayed allocation, and
> so it fragmenting the file itself with it's write pattern.
> Basically, that's a bug in systemd, and not something the filesystem
> can avoid because userspace is directly controlling block
> allocation.

hohum, I guess we should look into this.

OTOH: nothing wrong with calling posix_fallocate() if you need the space
guarantees it provides for proper operation...

-Eric

> Cheers,
> 
> Dave.
> 

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