From: Taras Glek <tglek@mozilla.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: Minimizing fragmentation in ext4, fallocate not enough?
Date: Mon, 27 Sep 2010 14:10:52 -0700 [thread overview]
Message-ID: <4CA1085C.5090206@mozilla.com> (raw)
In-Reply-To: <4C9E30B7.1050607@redhat.com>
On 09/25/2010 10:26 AM, Eric Sandeen wrote:
> Andreas Dilger wrote:
>> On 2010-09-24, at 18:05, Taras Glek wrote:
>>> I noticed that several random IO-heavy Firefox files got fragmented
>>> easily. Our cache suffers most. The cache works by creating a flat
>>> file and storing fixed-size entries in it. I though if I
>>> fallocate() the file first, then all of the writes within the
>>> allocated area would not cause additional fragmentation.
>>>
>>> This doesn't seem to completely cure fragmentation with ext4 in
>>> 2.6.33. If I allocate a 4mb file, it gets more and more fragmented
>>> over time. fallocate() does reduce fragmentation, but not as much
>>> as I expected.
>> Have you checked filefrag immediately after fallocating the file? Is
>> it OK?
>>
>> It may be that the issue is that an fallocate()'d file is using
>> "unwritten extents" and converting these extents to "normal" extents
>> may cause apparent fragmentation. However, depending on which
>> version of e2fsprogs/filefrag you are using, it may well be that
>> these extents only appear to be fragmented due to the different
>> extent types.
> Agreed, please include filefrag (-v) output right after it's fallocated,
> and also when you see this fragmentation, and then we'll have a better idea
> about what you're seeing. And, the newer the filefrag the better. :)
Thanks for clarification. Turns out ext4 is performing as expected,
nevermind my previous message.
I was confused by discrepancy in number of extents reported by filefrag
1.41.10 with/without -v flag.
filefrag _CACHE_003_
_CACHE_003_: 17 extents found
filefrag -v _CACHE_003_
Filesystem type is: ef53
File size of _CACHE_003_ is 4194304 (1024 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 232448 128
1 128 232576 1 unwritten
2 129 232577 95
3 224 232672 1 unwritten
4 225 232673 31
5 256 232704 1 unwritten
6 257 232705 63
7 320 232768 1 unwritten
8 321 232769 95
9 416 232864 1 unwritten
10 417 232865 255
11 672 233120 1 unwritten
12 673 233121 191
13 864 233312 1 unwritten
14 865 233313 127
15 992 233440 3
16 995 233443 29 unwritten,eof
_CACHE_003_: 1 extent found
Thanks,
Taras
next prev parent reply other threads:[~2010-09-27 21:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-25 0:05 Minimizing fragmentation in ext4, fallocate not enough? Taras Glek
2010-09-25 1:07 ` Andreas Dilger
2010-09-25 17:26 ` Eric Sandeen
2010-09-27 21:10 ` Taras Glek [this message]
2010-09-27 21:16 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CA1085C.5090206@mozilla.com \
--to=tglek@mozilla.com \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox