From: Ed Sweetman <ed.sweetman@wmich.edu>
To: Alex Tomas <bzzz@tmi.comex.ru>
Cc: linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: [RFC] extents support for EXT3
Date: Fri, 29 Aug 2003 15:55:14 -0400 [thread overview]
Message-ID: <3F4FAFA2.4080202@wmich.edu> (raw)
In-Reply-To: <m3ad9snxo6.fsf@bzzz.home.net>
Well, it appears that you need about 10+ blocks per extent to see any
noticable performance gain. The problem is most files are not large
enough to achieve this. Most range from a few kB to a couple mB. High
activity directories like /tmp and /usr deal mostly with numerous small
files. Now the reason i bring this up is that extents basically make
your fs incompatible with any kernel not compiled with the patch, which
means if something bad happened and you needed to use a bootable cdrom
with some safety kernel, it wouldn't be that useful. for such small
improvements, it doesn't seem worth the risk to make / or directories
like /tmp,/var,/usr,/boot,/lib etc, with extents. The files just dont
get large enough to make performance gains worth more than backward
compatibility.
Now for media, like music and movies and such, this makes a lot of
sense. Files get large enough so that the block to extent use is very
high and the files aren't necessary to use the system. extents are 5
seconds faster when md5summing a 622MB file than the same file written
without extents enabled.
I would not recommend using the patch for system directories only
because it leaves you with no way to rescue the system and does very
little in the way of performance for those directories. Ext3 is
backwards compatible with ext2, this patch seemingly breaks that.
Because of that it doesn't seem to be ext3 anymore, rather a one way
compatibility with ext3 with a purely large media bias.
Alex Tomas wrote:
>>>>>>Ed Sweetman (ES) writes:
>
>
> ES> Throughput 221.812 MB/sec 16 procs ext2
> ES> Throughput 159.495 MB/sec 16 procs ext3-extents (definitely enabled)
> ES> Throughput 147.598 MB/sec 16 procs ext3 (patched but disabled)
>
> ES> There is an obvious improvement, but nothing near the 70+% increase
> ES> you saw. Subsequent runs run anything from a little lower than above
> ES> for extents to 167MB/s.
>
> it seems one of my scsi drive is a bit broken (caching, at least).
> sorry for invalid numbers. on another drive I see following:
>
> w/o extents:
> [root@zefir root]# /root/db2.sh 2 16
> Throughput 119.199 MB/sec 16 procs
> Throughput 106.09 MB/sec 16 procs
> Average: 112.64450
>
>
> with extents:
> [root@zefir root]# /root/db2.sh 2 16
> Throughput 156.846 MB/sec 16 procs
> Throughput 170.591 MB/sec 16 procs
> Average: 163.71850
>
> so, this time improvement is about 45%
next prev parent reply other threads:[~2003-08-29 19:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-28 8:22 [RFC] extents support for EXT3 Alex Tomas
2003-08-28 17:22 ` [Ext2-devel] " Mike Fedyk
2003-08-29 5:55 ` Alex Tomas
2003-08-28 18:12 ` Ed Sweetman
2003-08-29 5:59 ` Alex Tomas
2003-08-29 15:28 ` Ed Sweetman
2003-08-29 15:38 ` Alex Tomas
2003-08-29 15:52 ` Ed Sweetman
2003-08-29 16:10 ` Alex Tomas
2003-08-29 16:16 ` Alex Tomas
2003-08-29 16:20 ` Ed Sweetman
2003-08-29 16:34 ` Alex Tomas
2003-08-29 17:49 ` Ed Sweetman
2003-08-29 18:09 ` Alex Tomas
2003-08-29 19:55 ` Ed Sweetman [this message]
2003-08-29 21:39 ` [Ext2-devel] " Mike Fedyk
2003-08-29 22:25 ` Ed Sweetman
2003-08-29 23:17 ` Mike Fedyk
2003-08-31 20:25 ` Eric W. Biederman
2003-08-31 20:37 ` Alex Tomas
2003-09-05 10:06 ` Pavel Machek
2003-09-05 14:55 ` Eric W. Biederman
2003-08-30 9:09 ` Alex Tomas
2003-08-30 8:55 ` Alex Tomas
2003-08-30 10:13 ` Alex Tomas
2003-08-28 22:00 ` Ramón Rey Vicente
2003-08-29 6:04 ` Alex Tomas
2003-08-29 9:55 ` Ramón Rey Vicente
2003-09-06 0:19 ` jw schultz
2003-09-06 6:09 ` Alex Tomas
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=3F4FAFA2.4080202@wmich.edu \
--to=ed.sweetman@wmich.edu \
--cc=bzzz@tmi.comex.ru \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@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).