From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: don't load the block bitmap for block groups which have no space
Date: Mon, 13 Aug 2012 13:51:16 -0500 [thread overview]
Message-ID: <50294CA4.90100@redhat.com> (raw)
In-Reply-To: <20120813184916.GF32484@thunk.org>
On 8/13/12 1:49 PM, Theodore Ts'o wrote:
> On Mon, Aug 13, 2012 at 11:02:08AM -0500, Eric Sandeen wrote:
>>
>> Looks ok to me; I think this just further optimizes what was done
>> in
>>
>> 8a57d9d61a6e361c7bb159dda797672c1df1a691
>> ext4: check for a good block group before loading buddy pages
>>
>> correct?
>
> Yes, that's right; it's a further optimization.
>
> I can think of an additional optimization where if we are reading the
> block bitmap for block group N, and the block bitmap for block group
> N+1 hasn't been read before (so we don't have buddy bitmap stats), and
> the block bitmap for bg N+1 is adjacent for bg N, we should read both
> at the same time. (And this could be generalized for N+2, N+3, etc.)
>
> I'm not entirely sure whether it's worth the effort, but I suspect for
> very full file systems, it might be very well be. This is a more
> general case of the problem where most people only benchmark mostly
> empty file systems, and my experience has been that above 70-80%
> utilization, our performance starts to fall off. And while disk space
> is cheap, it's not _that_ cheap, and there are always customers who
> insist on using file systems up to a utilization of 99%, and expect
> the same performance as when the file system was freshly formated. :-(
I did some tests w/ very large filesystems, fallocating 1T at a time until
full. ext4 tended to fall down pretty badly towards the end. Anything that
can reduce the time it takes to find free blocks as a very large filesystem
fills would probably be useful....
-eric
> - Ted
>
next prev parent reply other threads:[~2012-08-13 18:51 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 ` [Bug 45741] " bugzilla-daemon
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 [this message]
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=50294CA4.90100@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.