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 13:49:51 -0400 [thread overview]
Message-ID: <3F4F923F.9070207@wmich.edu> (raw)
In-Reply-To: <m3isogpgna.fsf@bzzz.home.net>
Alex Tomas wrote:
>>>>>>Ed Sweetman (ES) writes:
>
>
> ES> I was testing this with only a single partition mounted with extents
> ES> enabled when benchmarking. Ext3 gave no messages of being mounted
> ES> afterbootup with or without extents so to make sure i had extents
> ES> enabled i booted with all my partitions with the extents option. I
> ES> suspect then my problems began. I'm completely unaware of the extent
> ES> of the damage enabling extents has done since most of the important
> ES> things were opened, not created during my extents use. In any case it
> ES> may be that the reason why init is not able to be found is because i
> ES> used apt and upgraded my system ...and I dont remember if i had
> ES> extents enabled at the time or not. If my init is in extents format
> ES> though, then why is a patched kernel able to read it with extents not
> ES> being enabled via the omunt option where as kernels without the patch
> ES> cannot. Is extents able to be read from a fs even when it's not
> ES> mounted with the option but not written? I'm kinda confused, this
> ES> aspect of extents wasn't in the original email.
>
> well, on my testbox I use _patched with extents_ ext3 as / and /boot partitions.
> I haven't seen any problems on them. with patch, ext3 look at special EXTENTS
> flag in inode (this flag is set up only for newly created files on fs being
> mounted with extents enabled) and calls apropriate routines. thus, it will
> call extents routines for those file even if fs is being mounted with extents
> disabled. I really do believe that your root filesystem haven't been mounted
> with extents enabled, so init must be stored in good old format.
Ok well little wait on the non-patched bootup.
I booted with test4-mm2 patched
Throughput 221.812 MB/sec 16 procs ext2
Throughput 159.495 MB/sec 16 procs ext3-extents (definitely enabled)
Throughput 147.598 MB/sec 16 procs ext3 (patched but disabled)
There is an obvious improvement, but nothing near the 70+% increase you
saw. Subsequent runs run anything from a little lower than above for
extents to 167MB/s.
I'm using the largest inode size possible for ext3 for the filesystem
tested.
By the way, what's the behavior of opening an existing non-extent file
and writing and reading to it while the partition is mounted with
extents enabled?
> ES> i'm going to try and boot a kernel without the extents patch (so far
> ES> hasn't been possible) and run dbench again and see if i get different
> ES> numbers. I'm almost suspecting extents being enabled no matter what i
> ES> mount the fs's as.
>
> that would be fine!
>
>
next prev parent reply other threads:[~2003-08-29 17:50 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 [this message]
2003-08-29 18:09 ` Alex Tomas
2003-08-29 19:55 ` Ed Sweetman
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=3F4F923F.9070207@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).