Page 7 of 9 FirstFirst ... 56789 LastLast
Results 61 to 70 of 90

Thread: Ubuntu 9.04 vs. Mac OS X 10.5.6 Benchmarks

  1. #61
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by kraftman View Post
    I did some SQLite tests in KVM and Ext3 is really slow when compared to Ext4:

    http://img75.imageshack.us/img75/671...ultssqlite.png

    http://img75.imageshack.us/img75/933...ultssqlite.png

    It probably means Ext4 and HFS+ are using cache and Ext3 isn't. Or Ext 3 just sux

    P.S. results are reproducible.

    P.S.2 If TeeKee is right (and probably is) this Phoronix benchmark sux a little...
    If true that's a freakishly big difference in performance between ext3 and 4. From what I know I wouldn't be too surprised if HFS+ beat ext3. ext3 is stable but quite old and fairly slow.

    So, definitely sounds like more tests should be done, yup.

    Or maybe this was just a ploy to get more Linux users on Phoronix to try to one-up Mac.

  2. #62
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,068

    Default

    I checked the previous results between Ubuntu 8.10 and MacOSX 10.5. Fortunately there was there a 64 bit benchmark. You can see that in a lot of tests were MacOSX beats Ubuntu 32, the true winner is the 64 flavour of Linux, like mp3 and ogg enconding and 7zip compression. Unfortunately no ext4 back then. Oh come on Michael, give us a real benchmark

  3. #63

    Default

    Ubuntu 64-bit results are coming soon

  4. #64
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,068

    Default

    Quote Originally Posted by Michael View Post
    Ubuntu 64-bit results are coming soon
    Dabadabadu

  5. #65

    Default

    I should also note that tomorrow there are OpenSolaris vs. Linux kernel benchmarks (using Nexenta CP2) tomorrow with both Ubuntu 32-bit and 64-bit, but it's unrelated and on a different test system.

  6. #66

    Default

    Quote Originally Posted by Michael View Post
    Ubuntu 64-bit results are coming soon
    Great, can we expect Ext 4 benchmarks too?

    @Xfrwlf

    If true that's a freakishly big difference in performance between ext3 and 4. From what I know I wouldn't be too surprised if HFS+ beat ext3. ext3 is stable but quite old and fairly slow.
    It's probably, because Ext 3 doesn't support delayed allocation. Strange thing is each of the first tests has worse results then the second and the third. It may be due to some scripts in Ubuntu which consume 100% CPU time while after booting. 'Top' shows python using 100% CPU for a while.
    Last edited by kraftman; 05-14-2009 at 12:27 PM.

  7. #67
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    isn't easier to you just to test Fedora with 2.6.30 ext4 on mac mini?

  8. #68
    Join Date
    May 2009
    Posts
    25

    Default

    The test compared only 32 bit linux with an operating system (Mac OS) that has 64 bit "extensions". It would have been better to include 64 bit ubuntu as well like you did on last year's test.

    Also you did not use ext4. I have been using it for some time (a month or so) and i can confirm that it makes a big difference on my machine (24'' iMac)

  9. #69
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by Yfrwlf View Post
    If true that's a freakishly big difference in performance between ext3 and 4. From what I know I wouldn't be too surprised if HFS+ beat ext3. ext3 is stable but quite old and fairly slow.

    So, definitely sounds like more tests should be done, yup.

    Or maybe this was just a ploy to get more Linux users on Phoronix to try to one-up Mac.


    Alright... here is the skinny on Ext3 and SQLite performance.

    As you probably know.. most modern systems use asyncronous write file systems. This means that when a program writes out a file that file is not immediately written to disk. So the OS uses file system cache to make the illusion that the data is written out, so your application can read/write to files without caring.

    This is done to improve performance, improve multitasking performance, improve file system layout on the drive to avoid fragmentation, etc.

    Ext3, with it's defaults, means that it can take up to 5 seconds for data to get commited to disk.

    --------------------------

    Alright.

    So the upside is better performance and efficiency.

    The downside is that if your system crashes, power goes out, or other things go bad then the system won't have time to commit the changes to disk and you will end up with corruption or missing data.

    To combat this most modern file systems use a form of journaling. Journaling means that a record of what is getting writen to disk is kept so that during system recovery you can replay the journal and compinsate for any damage.

    Previously you would have to run a fsck on every poor shutdown, which takes a long time.

    -------------------


    The next thing to understand is that another technique to combat changes of file corruption is that applications can request things like 'sync()' or 'fsync()'

    This tells the file system to commit data to the disk immediately, as soon as possible.

    Applications like Vim, OpenOffice.org, Emacs and other well designed applications use that when you save your work so that there is little chance of data corruption with your important files. Most stuff that happens is not that important so that they don't request fsync all the time.

    Fsync is 'file sync' and only should affect one file and the other is sync, which is a system-wide commit and is rarely done due to the huge performance penalty. There is a command called 'sync' that you can use that will perform a 'sync()' call for you.

    ----------------------------


    Ext3 is designed to work on commodity hardware effectively.

    Most file systems like XFS or ReiserFS that are designed for high performance are expecting that you are using battery-backed harddrive cache and UPSes and all that stuff to protect your system.

    Ext3 tries to be quite a bit more robust. Because of this Ext3 supports multiple journaling modes which are configurable using mount-time options.

    The options are:

    data=journal
    ------------

    This is the most robust design. Both data and metadata* is journaled.

    That means that all your data gets writen to the drive twice.. once for the journal and then once again when it actually gets commited to disk.

    The downside to this mode is that it's only rarely used so it isn't as well tested as other modes.

    *metadata is 'data about data'. This is the stuff that the file system keeps track of. Filenames, file locations, file permissions, timestamps, etc etc.

    data=writeback
    --------------

    This is the fastest mode. This mode matches what other journaling FSs like NTFS, XFS, ReiserFS, and I expect HFS+ uses. With this mode only Metadata is journaled and data is writen willy-nilly.. at any time.

    With this it's designed to simply protect the file system from corruption. Individual files may end up with missing or corrupt data during a failure, but the file system is kept track of.


    data=ordered
    -------------

    This is the default mode for Ext3.

    With this mode only the metadata is journaled, however data gets written FIRST. This means that any changes to the data on the harddrive has to be written out before the file system on the drive is updated to reflect changes.

    This ensures that you won't have empty files or half-written or otherwise corrupted files on a failure. You may miss new data, but old data won't be corrupted. Only fully written files are recorded.



    ----------------------

    Now data=ordered helps Ext3 be more secure and be more robust then typical journaling file systems.

    However due to this design you have some negative performance side effects with SQLite.


    Ok....

    Remember back when Firefox was causing machines to 'freeze up' for short times and cause other bad performance problems on Linux? Well that was done because of Firefox using SQLite. This was due to a combination of the I/O schedualer and the 'data=ordered' feature.

    So your system is heavily using cache to improve performance. So the kernel sets up a write queue to keep track of what data should be written to disk.. it'll look something like this:

    write, write, write, metadata, metadata, write, write, etc etc.

    While the I/O queue just stuck the 'fsync()' command on the end of the queue... and since 'fsync()' says "WRITE THIS DATA NOW" and 'data=ordered' says "write data before updating file system metadata"...

    So this transformed 'fsync' into 'sync'. The Linux kernel would flip out and write all the data and metadata in order to do the fsync() correctly.

    And since Firefox used SQLite and SQLite requested 'fsync()' very often this problem would happen all the time while using firefox.


    ------------------------------


    To fix this newer versions of the I/O scedular in the Linux kernel created a second queue for high-priority writes. So that way fsync() won't get transformed into sync.

    However the 'data=ordered' still causes latency issues and they can't figure out how to make the schedualer work correctly.

    -------------------------------


    So to fix that they have changed the default in Linux 2.6.30 from 'data=ordered' to 'data=writeback'.

    So this way this solves the majority of the problem with Ext3.

    However distributions probably won't use this.

    Why?

    Because it lowers the security and robustness of Ext3.

    Because the file system on the harddrive is updated, possibly, before a file is written to disk you can end up with situations were you have files created with just random junk in it if the system fails. That random junk may be other people's important data. Important configuration files, passwords, bank statements, etc etc.

    So on multiuser systems this can cause a security hole.

    To solve this problem a new mode is being created called 'data=guarded'. This solves the security issues, but keeps most of the performance of 'data=writeback'.

  10. #70
    Join Date
    Dec 2008
    Posts
    315

    Default

    If you can get Enron accountants to write your journaling data structures can you be rich until your system crashes?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •