xfs
[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: XFS on 2.6.26: reading the first 4K of a large file takes ages
From: Florian Weimer <fweimer@xxxxxx>
Date: Thu, 20 May 2010 12:11:00 +0000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20100519114826.GA18224@xxxxxxxxxxxxx> (Christoph Hellwig's message of "Wed\, 19 May 2010 07\:48\:26 -0400")
References: <8239xojfco.fsf@xxxxxxxxxx> <20100519114826.GA18224@xxxxxxxxxxxxx>
* Christoph Hellwig:

> On Wed, May 19, 2010 at 11:33:27AM +0000, Florian Weimer wrote:
>> We've got a couple of rather large files, and with a cold cache,
>> reading the first 4K bytes of the file (e.g., just running
>> "head --bytes 4096" on it) takes ages, up to several minutes,
>> sometimes triggering the hang check timer.
>> 
>> I wonder if XFS reads the whole extent information into RAM when the
>> file is opened.  Is this the case, at least on 2.6.26?  Has this
>> changed in later versions, perhaps?
>
> Yes, XFS always reads in the extent map, and no this hasn't changed
> recently.

Okay, defragmenting seems to improve things considerably.  But it's
going to take a while: "extents before:5309152 after:13" *sigh*

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).

-- 
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>