public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

  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