Slashdot Mirror

← Back to Stories (view on slashdot.org)

Huge Increase for Ext2/Ext3 Performance

Posted by chrisd on 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"

52 comments

  1. So... by Spokehedz · · Score: 1

    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.

    1. Re:So... by psavo · · Score: 0, Troll

      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.

      Do I have to explain everything?
      Simple. MOER FERKIN' PR0N, FESTER, FESTER!!!

      --
      fucktard is a tenderhearted description
    2. Re:So... by Spokehedz · · Score: 0, Troll

      *LAUGHING* How did that get a +2 score? Aww, who cares--its Slashdot. News for Neanderthals. Stuff that is inconsequential. right?

    3. Re:So... by Anonymous Coward · · Score: 0

      >>> *LAUGHING* How did that get a +2 score?

      If a user has lots of karma, they can post at 2, wheras most people post at 1.

      We special high-karma folks have privledges...

    4. Re:So... by Spokehedz · · Score: 0, Offtopic

      Quote:
      We special high-karma folks have privledges...

      Said the AC from Oblivion...

    5. Re:So... by Anonymous Coward · · Score: 1, Insightful

      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....

    6. Re:So... by Anonymous Coward · · Score: 0

      Fucking newbie. On AOL, the corrct term is LOL, not *laughing*. If you're going to play the role of a flaming gay hairdresser with an AOL account, at least get the lingo right.

      EVERYONE who says LOL or ROTFLMAO is a flaming gay AOL hairdresser. And if you'd been around you'd know that. So, you must be a newbie.

    7. Re:So... by Spokehedz · · Score: 1

      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.

    8. Re:So... by Spokehedz · · Score: 0, Offtopic

      Riiiight.

    9. Re:So... by ivan256 · · Score: 4, Informative

      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?

    10. Re:So... by Anonymous Coward · · Score: 0

      And all users have the option of posting as AC if they want. I just don't care enough about this offtopic conversation to post with my normal name...

      So gee whiz, what's with the flames?

    11. Re:So... by psavo · · Score: 3, Informative

      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.

      --
      fucktard is a tenderhearted description
    12. Re:So... by Anonymous Coward · · Score: 0

      funny, does the +1 bonus work even on AC post?

    13. Re:So... by Spokehedz · · Score: 1

      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.

    14. Re:So... by psavo · · Score: 2

      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.

      --
      fucktard is a tenderhearted description
    15. Re:So... by Anonymous Coward · · Score: 0

      Especially considering we were saying things like LOL before AOL even existed :P

    16. Re:So... by Anonymous Coward · · Score: 0

      Which just goes to prove the poster's point, you pinko flaming-gay hairdresser, you. You look so butch it that sparkle top.

    17. Re:So... by ivan256 · · Score: 3, Informative

      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. --

    18. Re:So... by cornice · · Score: 3, Informative

      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...

    19. Re:So... by Anonymous Coward · · Score: 0

      I'm checking Google right now, and it appears that the earliest reference to LOL was Right here. That's May 8th, 1989. The first reference to America Online was Sept. 14th, 1989. So LOL does indeed predate America Online.

      However, it is still entirely true that LOL is very very gay.

    20. Re:So... by ActiveSX · · Score: 1

      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.

    21. Re:So... by Spokehedz · · Score: 0

      This is what I've been looking for--the net install disks. Thank you.

      However, the lack of a CD-burner problem still remains; I have a 60 GB RAID-0 formatted as NTFS that I wish to turn into a disk that I can use in Linux. And AFAIK, there isn't anything to convert NTFS to EXT2/3, and I need some of those files (drivers, mp3/OGG, pictures (vacation, not porn), etc.) off of it.

      I know I can read the NTFS disk, but that doesn't help me at all as I want to actually use the disk as a read/writeable disk--not a read-only disc.

      So you see, the CD-Burner wasn't just for the ISO's (I didn't know about the net install at the time) to be burned. It was to preserve my files on the migration over to the new system.

      But thank you for the honest and informative reply to my questions, even when they were OT.

    22. Re:So... by Anonymous Coward · · Score: 0

      I don't know about XP, but I know in windows 2000, you can dynamically convert an NTFS partition to a "dynamic volume" or whatever they call it, and then back. You can do it in the disk manager utility. I'm pretty sure that you can resize your NTFS volume if you convert it first, and then switch it back to a regular style partition so you can mount it from linux. (Still read-only, but you'll have empty space for your ext2/3 partition).

  2. Wow... by avalys · · Score: 0, Offtopic

    Who let that mess slip through?

    --
    This space intentionally left blank.
  3. Windows/Mac by dalutong · · Score: 4, Interesting

    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?

    --

    What comes first, finding a teacher or becoming a student?
  4. lots-a- small files by drDugan · · Score: 3, Informative

    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.

    1. Re:lots-a- small files by benjamindees · · Score: 2, Insightful

      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?

      --
      "I assumed blithely that there were no elves out there in the darkness"
    2. Re:lots-a- small files by cookd · · Score: 1

      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.

      --
      Time flies like an arrow. Fruit flies like a banana.
    3. Re:lots-a- small files by 0x0d0a · · Score: 2

      (/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...:-)

      --
      May we never see th
    4. Re:lots-a- small files by cookd · · Score: 1

      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 : )

      --
      Time flies like an arrow. Fruit flies like a banana.
    5. Re:lots-a- small files by 0x0d0a · · Score: 2

      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...)

      --
      May we never see th
    6. Re:lots-a- small files by Anonymous Coward · · Score: 0

      FAT/FAT32 is WAY slower than ext2. BSD is slower than ext2 ... everyone trashes ext2 for designing for speed rather robustness. Ext2 is possibly slower than newest versions of NTFS (but NTFS was a pig in NT4.0) but is much much much faster than fat32.

  5. 170% increase on deleting kernel tree by wcbarksdale · · Score: 4, Funny

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

    1. Re:170% increase on deleting kernel tree by tim0thy · · Score: 1

      Yeah, you can 'rm -rf /' a company's system 170% faster right after you get laid off!

  6. Re:The Future of Slashdot and FREEBSD tsarkon repo by glenstar · · Score: 2
    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".

  7. Re:The Future of Slashdot and FREEBSD tsarkon repo by Anonymous Coward · · Score: 0

    hahahahaha. hurd beta in 2008.

    ehehehe. poor Hurd. its like Mach. good on paper, but...........

  8. "170% increase on deleting kernel tree" by psyconaut · · Score: 5, Funny

    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

    1. Re:"170% increase on deleting kernel tree" by Hard_Code · · Score: 2

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

      --

      It's 10 PM. Do you know if you're un-American?
  9. Troll by Gerry+Gleason · · Score: 2
    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.

    1. Re:Troll by ActiveSX · · Score: 1

      No, he's saying that he's going to try Linux as soon as he gets a burner to make cds from a distro's ISOs.

  10. Without reading about the original patch... by 0x0d0a · · Score: 2

    ...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).

    --
    May we never see th
  11. Re:FreeBSD first, of course. by Anonymous Coward · · Score: 0

    Ooops, almost forgot...

    Signed,
    drdink

  12. Re:FreeBSD first, of course. by Anonymous Coward · · Score: 0

    Ooops, almost forgot...

    Signed,
    drdink

    LEAVE SOME CORNEAS FOR THE REST OF US, MOTHERFUCKER!!!!!

    christ. you really piss me off.

  13. Re:FreeBSD first, of course. by drdink · · Score: 2

    Cute. Lame, but cute.

    --
    Beware, Nugget is watching... See?
  14. Re:FreeBSD first, of course. by Anonymous Coward · · Score: 0

    :-)

  15. Re:FreeBSD first, of course. by Anonymous Coward · · Score: 0
    I almost forgot!

    Signed,
    jjayson the Homosexual!!!

  16. Re:FreeBSD first, of course. by Nugget · · Score: 1

    Linux is poo.