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

Florian Weimer fweimer at bfk.de
Fri May 21 01:43:15 CDT 2010


* Stewart Smith:

> On Thu, 20 May 2010 12:11:00 +0000, Florian Weimer <fweimer at bfk.de> 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 at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




More information about the xfs mailing list