xfs
[Top] [All Lists]

Re: XFS on 2.6.26: reading the first 4K of a large file takes ages

To: Stewart Smith <stewart@xxxxxxxxxxxxxxxx>
Subject: Re: XFS on 2.6.26: reading the first 4K of a large file takes ages
From: Florian Weimer <fweimer@xxxxxx>
Date: Fri, 21 May 2010 06:43:15 +0000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <87zkztojwh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (Stewart Smith's message of "Fri\, 21 May 2010 16\:20\:46 +1000")
References: <8239xojfco.fsf@xxxxxxxxxx> <20100519114826.GA18224@xxxxxxxxxxxxx> <82sk5m7oyz.fsf@xxxxxxxxxx> <87zkztojwh.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
* Stewart Smith:

> On Thu, 20 May 2010 12:11:00 +0000, Florian Weimer <fweimer@xxxxxx> wrote:
>> Thanks for confirming my hunch.  I don't think it's worth fixing this
>> in XFS.  The database should call posix_fallocate() before flushing
>> its internal cache to the file in essentially random order, but it's
>> difficult to get upstream to implement this (the source code is a bit
>> hard to follow, unfortunately).
>
> Which database?

Oracle Berkeley DB.

> You could always mount with allocsize

This happens with "allocsize=4194304".

> or use other tools to do the preallocation before things got too
> bad.

Is there a way to transparently preallocate a few GB after the current
end of the file?  That would be helpful because Berkeley DB wouldn't
have to know about it.

It's a legacy system, otherwise I would invest more effort into
putting some sort of preallocation somewhere deep into Berkeley DB.

-- 
Florian Weimer                <fweimer@xxxxxx>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

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