From: Ted Ts'o <tytso@mit.edu>
To: Bjoern Slotkowski <bjoern.slotkowski@imc-berlin.de>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: AW: Questions concerning ext2 filesystem: ext2_statfs
Date: Mon, 3 Jan 2011 17:24:51 -0500 [thread overview]
Message-ID: <20110103222451.GA2959@thunk.org> (raw)
In-Reply-To: <FPEIIEKCABPOOBGGCOCHOEMNDHAA.bjoern.slotkowski@imc-berlin.de>
On Mon, Jan 03, 2011 at 02:12:04PM +0100, Bjoern Slotkowski wrote:
>
> But there is still one thing also in the newer kernel:
> f_bfree and f_ffree are determined by functions "ext2_count_free_blocks" and
> "ext2_count_free_inodes"
> which iterate through s_groups_count which needs a lot of time.
>
> When I look at ext3/super.c and ext4/super.c the member variables
> s_freeblocks_counter and s_freeinodes_counter are used directly in functions
> *_statfs.
>
> Probably there is potential for an optimization.
Perhaps, but note that ext4 is fully backwards compatible with ext2.
That is, you can mount ext2 file systems using the ext4 file system
driver. (You can also mount ext2 file systems using the ext3 file
system, although you will have to add a journal to the file system
first.)
Ext2 is primarily useful as an working, example file system which
shows how to interface a file system to Linux. As such piling in too
many optimizations isn't necessarily consistent with its current role.
No one is really actively maintaining ext2, except to update it work
with the latest kernel interfaces, so it's not clear who would do the
optimization.
If you want a faster, more efficient file system, there are plenty of
alternatives, including ext3 and ext4.
- Ted
prev parent reply other threads:[~2011-01-03 22:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 12:14 Questions concerning ext2 filesystem: ext2_statfs Bjoern Slotkowski
2010-12-22 17:01 ` Andreas Dilger
2011-01-03 13:12 ` AW: " Bjoern Slotkowski
2011-01-03 22:24 ` Ted Ts'o [this message]
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=20110103222451.GA2959@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=bjoern.slotkowski@imc-berlin.de \
--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).