Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Huge Increase for Ext2/Ext3 Performance 52

Posted by chrisd from the speed-is-good dept.
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"
This discussion has been archived. No new comments can be posted.

Huge Increase for Ext2/Ext3 Performance More

Huge Increase for Ext2/Ext3 Performance

Comments Filter:
  • What does this translate into real-world usage? Or am I just another stupid Micro-Serf who doesn't get that _every_ percentage increase is an increase to write to Slashdot about.

    • Re:So... (Score:1, Insightful)

      by Anonymous Coward
      Even a 13% improvement is nice. It makes the fast system even faster...

      >>>Or am I just another stupid Micro-Serf who doesn't get that _every_ percentage increase is an increase to write to Slashdot about.

      No, you're just a micro-serf who's trying to antagonize people into an argument, as if that was original....
      • No, I asked a valid question, and then I simply short-cut what everyone would say about me when anyone asks why Linux does anything it does. Which is "Because it can."

        This was not for a flame--I honestly want to know if it is a huge increase, or a small increase. I'm planning on switching as soon as I get a new CDRW to burn the ISO's.

        Whatever. I'll get the "+1 Flamebait" and I'll live with it.

        • Re:So... (Score:4, Informative)

          by ivan256 ( 17499 ) on Tuesday November 05, 2002 @06:46PM (#4603600)
          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?
          • Well, as a Micro-serf... I don't recompile the Kernel too often. Nor do I compile much sourcecode on my system.

            And why don't I try the new kernel?

            *Puts on flame-proof armor*

            Because I'm still running WindowsXP.

            I'd like to switch--I really would. I can't burn the ISO's of the CD's because my burner won't work, and I can't buy the boxed set 'cause I'm broke.

            I'm gonna buy the 52x24x52 burner next pay. But until then, I'm stuck in Windows.
            • 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.
            • 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... (Score:3, Informative)

              by ivan256 ( 17499 )
              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... (Score:3, Informative)

          by psavo ( 162634 )
          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.
        • Whatever. I'll get the "+1 Flamebait" and I'll live with it.

          Yeah, I don't think anybody would object to getting their comment modded up, but flamebait is a -1. Slashdot would be a much different beast if it was +1, methinks.

    • Re:So... (Score:3, Informative)

      by cornice ( 9801 )
      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...
    • ...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).

  • Windows/Mac (Score:4, Interesting)

    by dalutong ( 260603 ) <djtansey@gmail.cCOFFEEom minus caffeine> on Tuesday November 05, 2002 @06:10PM (#4603273)
    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 (Score:3, Informative)

    by drDugan ( 219551 ) on Tuesday November 05, 2002 @06:27PM (#4603433) Homepage
    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.

    • 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?
    • Any well-written filesystem will push your video files around at about the same speed: the speed of your hard disk drive (assuming the files aren't too fragmented, which I suppose has some bearing on the filesystem). But in other tests, different filesystems make a huge difference.

      After uncompressing and compiling a tarball, I am always given a lovely opportunity to ponder the mysteries of the universe as the rm -r latest-extracted-tarball command runs. For some reason, the delete of a tree seems to go really slowly on both FreeBSD and Linux, while the same operation seems to be a lot faster under Windows (no benchmarks here, just vague generalizations).

      So this could make a real difference in real-life scenarios. The benchmarks listed are some of the more challenging performance hurdles for filesystem designers. If this doesn't hurt fragmentation rates, this sounds like a win-win.
      • (/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...:-)
        • Windows -- both NTFS and FAT seem to delete a tree much more quickly than FreeBSD's native format (UFS, no? I never actually pay attention when I'm setting things up, and I haven't had to install my BSD box for a long time...). I do most of my dev work on NTFS-based systems, and cleaning/clobbering the source trees gives me plenty of opportunity to get a feel for how quickly it can delete.

          Softupdates helped BSD, but not as much as I was hoping.

          I don't play around with Linux nearly as much as BSD and Windows. But because of my experiences with BSD, I tried a few experiments on a Linux box I had to mess around with (I'm pretty sure it was running ext2) and the results were comparable with FreeBSD's.

          Like I said, these are vague generalizations. I never took two samples on the same hardware, never used a stopwatch. But extracting and then deleting the PHP tarball and its corresponding tree is much faster on my Windows XP box than on my FreeBSD box. YMMV : )
          • 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 (Score:4, Funny)

    by wcbarksdale ( 621327 ) on Tuesday November 05, 2002 @06:33PM (#4603494)
    Imagine how quickly you can rm -rf / now...

  • "170% increase on deleting kernel tree" (Score:5, Funny)

    by psyconaut ( 228947 ) on Tuesday November 05, 2002 @06:55PM (#4603661)
    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

Slashdot Top Deals

To the landlord belongs the doorknobs.

Close