linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 45741] ext4 scans all disk when calling fallocate after mount on 99% full volume.
Date: Thu,  9 Aug 2012 18:10:59 +0000 (UTC)	[thread overview]
Message-ID: <20120809181059.A5BAA11FC69@bugzilla.kernel.org> (raw)
In-Reply-To: <bug-45741-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=45741


Theodore Tso <tytso@mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu




--- Comment #1 from Theodore Tso <tytso@mit.edu>  2012-08-09 18:10:59 ---
It's not scanning every single inode (that would take a lot longer!), but it is
scanning every single block allocation bitmap.   The problem is that we know
how many free blocks are in a block group, but we don't know the distribution
of the free blocks.  The distribution (there X blocks of size 2**3, Y blocks of
size 2**4, etc.) is cached in memory, but the first time you unmount and mount
the file system, we need to read in the block bitmap for a block group.

Normally, we only do this until we find a suitable group, but when the file
system is completely full, we might need to scan the entire disk.

I've looked at mballoc, and there are some things we can fix on our side. 
We're reading in the block bitmap without first checking to see if the block
group is completely filled.  So that's an easy fix on our side, which will help
at least somewhat.   So thanks for for reporting this.

That being said, it's a really bad idea to try to use a file system to 99%. 
Above 80%, the file system performance definitely starts to fall off, and by
the time you get up to 95%, performance is going to be really awful.  There are
definitely things we can do to improve things, but ultimately, it's something
that you should plan for.

You could also try increasing the flex-bg size, which is a configuration knob
when the file system is formatted.  This collects allocation bitmaps for
adjacent block groups together.  The default is 16, but you could try bumping
that up to 64 or even 128.  It will improve the time needed to scan all of the
allocation bitmaps in the cold cache case, but it may also decrease performance
after that, when you need to allocate and delalocate inodes and blocks, and by
increasing the distance from data blocks to the inode table.   How much this
tradeoff will work is going to be very dependent on the details of your
workload.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

  reply	other threads:[~2012-08-09 18:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08 16:42 [Bug 45741] New: ext4 scans all disk when calling fallocate after mount on 99% full volume bugzilla-daemon
2012-08-09 18:10 ` bugzilla-daemon [this message]
2012-08-10 18:21   ` [PATCH] ext4: don't load the block bitmap for block groups which have no space Theodore Ts'o
2012-08-13 16:02     ` Eric Sandeen
2012-08-13 18:49       ` Theodore Ts'o
2012-08-13 18:51         ` Eric Sandeen
2012-08-13 23:20         ` Andreas Dilger
2012-10-15 21:24 ` [Bug 45741] ext4 scans all disk when calling fallocate after mount on 99% full volume bugzilla-daemon
2012-11-08 14:21 ` bugzilla-daemon

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=20120809181059.A5BAA11FC69@bugzilla.kernel.org \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).