Huge Increase for Ext2/Ext3 Performance

pixelbeat writes "Grigory Orlov origonally implemented this new allocator for FreeBSD, and it's been merged in 2.5.46 and the first benchmarks are in: http://marc.theaimsgroup.com/?l=linux-kernel&m=103 650970512510&w=2 In summary: 13% increase on unpacking a kernel tarball 43% increase on uncached kernel tree traversal 48% increase on cached kernel tree traversal 170%increase on deleting kernel tree"

Comments

Windows/Mac

[dalutong]

Since this is just a test of unpacking and deleting lots of files... couldn't one do this test in Windows/Mac OSX to see how their file systems match up.

Does anyone have any benchmarks comparing them?

lots-a- small files

[drDugan]

typically I don't deal with thousands of small files at once.

I wonder how much better it does it do on the 650 MB video files I push around.

Re:lots-a- small files

[benjamindees]

This would be more of a test of your hard drive than the filesystem. If you just need to manipulate one big file, you don't really need a filesystem, then, do you?

Re:lots-a- small files

[0x0d0a]

(/me interested) You're using what filesystems here on Linux, FreeBSD, and Windows?

Having any performance area in which Windows beats Linux is a black eye...:-)

Re:lots-a- small files

[0x0d0a]

Hmm...

The problem here is that there are a lot of variables involved.

* The fullness of the partition is an issue.
* Whether the OS is using write caching is an issue
* Whether the drive is using write caching is an issue.
* The speed of the drive is an issue
* The location of the partition on the drive is an issue.

I haven't tried timed deletes, but FAT in general seems significantly slower than ext2/3. Could be just the fact that I usually use FAT on 9x, which has a lousy I/O subsystem. I don't really have any comparable boxes that have Windows and Linux on them to compare, though.

Oh, one other question -- are you mounting noatime? I always mount noatime (the constant bloddy disk accesses drive me mad otherwise...)

170% increase on deleting kernel tree

[wcbarksdale]

Imagine how quickly you can rm -rf / now...

Re:The Future of Slashdot and FREEBSD tsarkon repo

[glenstar]

You are not very nice... funny, but not very nice... ;-)

You forgot one very import event: in 2008, the Gnu HURD will be in "beta".

Re:So...

[ivan256]

I honestly want to know if it is a huge increase, or a small increase.

As in all things benchmarking related, the answer is: It depends. This will be significant for certain uses of your system, but unimportant for others. If you've got a very busy file server, a news server, or a build machine where you do alot of compilation, this will be very significant. For other tasks you might not even notice.

This is a kernel change, so there won't be any ISOs. Why not just try it now?

Re:So...

[psavo]

it depends largely on what you do. If you handle many small files a lot, this would be an imporvement. For bigger files it's not yet known. In theory it could speed up an httpd when clients access lots of different static html files. Also nntpd (news) would be afected. maildir / imap servers could benefit too.

"170% increase on deleting kernel tree"

[psyconaut]

Speed increase on rm -r /: 170%
Likelyhood of keeping your job after doing this: 0%
Seeing your boss's face when you tell him: priceless

-psyco

Re:"170% increase on deleting kernel tree"

[Hard_Code]

Is there any speed increase for the second run of rm -r / ?

Re:So...

[psavo]

borrow a debian cd. if it's new enough (2.0 or something around there), it'll update itself all the way up. (you need a broadband connection though). Debian is also installable from 2 floppies (network install grabs everything from net). I believe mandrake & Redhat have those too.

Troll

[Gerry Gleason]

So, what you are saying is that the original comment was just a troll. If you don't use and are not interested in using Linux, then why are you commenting.

Since there are a large number of problems that are essentially disk bound, this is probably more important than an equal improvement in CPU speed.

Re:So...

[ivan256]

I'm assuming you have a fast net connection. If you don't, please disregard...

Download the debian boot-floppies. You can do a full net instalation, and you'll only install what you need instead of downloading the entire contents of some distro's ISOs.

If you're not afraid of trying a development kernel with a beta filesystem patch, then the debian installation process should be simple.

Seriously, though. It looks like this new filesystem patch isn't quite ready. They're still finding leaked blocks and other corruption. You should run a "stable" kernel on your primary box, or you should do frequent backups! My primary workstation is running 2.4.17 (Hasn't had any downtime since 2.4.17 was released, so I haven't upgraded.), and I reserve the 2.5 series kernels for the rack of test machines behind me. If they break it's OK, but if I loose my emacs session I get seriously pissed off.

-- No need for flameproof armor. My home box runs windows most of the time. I hack Linux all day at work, so I want to use my home box for gaming. No better OS for that right now than windows. --

Re:So...

[cornice]

I don't know much about the patch but if I can get similar results then this is huge. Think about the things that you do on your computer that cause you to wait. I bet most of them are associated with disk IO eg booting, loading Word, Mozilla, etc. Now imagine these things taking significantly less time - without a hardware upgrade. Sounds good to me. I'm just waiting to the YMMV disclaimer...

Without reading about the original patch...

[0x0d0a]

...I strongly suspect that this allocater has both good cases and bad cases (particularly given how mature ext2 is).

I'm actually using it ATM, but it wouldn't surprise me if it does something nasty (like increase fragmentation under low-free-space conditions or something).

Re:FreeBSD first, of course.

[drdink]

Cute. Lame, but cute.