Announcement

Collapse
No announcement yet.

EXT3, EXT4, Btrfs Ubuntu Netbook Benchmarks

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Hi I'm not Canonical

    Michael:

    I thought from previous articles I read Ext4 had regressed substantially.

    Also did you ever pin down what caused the data loss from the video card tests?

    Any word out of Google about their move to ext4?

    Comment


    • #32
      Originally posted by mtippett View Post
      The intent of the test is to show the FS performance, and to simulate some contrived situations where people can't do transactions (like a busy 2-tier PHP site. The 3rd tier allows you to aggregate transactions, but a 2-tier won't)..
      I'm not sure what you exactly mean by those tiers, but if you mean lots of people with lots of databases (or even database engines) on the same machine then your sqlite test is flawed - it performs many serialized micro transactions instead of many parallel macro transactions. (I hope you can see the difference and the conclusions yourself.)

      Comment


      • #33
        Originally posted by cl333r View Post
        I wouldn't use ntfs for storing data for it isn't posix compatible so you loose meta info (like whether the file is executable or not) when storing files, not to mention that writing to ntfs (for me) is (a lot) slower than to ext4 under Linux. Also, it's enemy's territory. Can't wait for the final btrfs and see whether it delivers what it promises.
        Plus cpu usage goes way up when writing/reading large amounts of data (or perhaps just large files) from an ntfs disk. At least it did in Jaunty. I've since moved all my ntfs-housed data to my ext4 partition.

        Comment


        • #34
          So might one recommend btrfs over ext4 for lucid?

          Comment


          • #35
            Originally posted by molecule-eye View Post
            So might one recommend btrfs over ext4 for lucid?
            What do you have against plain old xfs or jfs?

            Comment


            • #36
              Originally posted by phtpht View Post
              What do you have against plain old xfs or jfs?
              Why would you think I have anything against them? I was just wondering, given the results of the article, if anyone would recommend btrfs over ext4. What do you have against kaleidoscopes?

              Comment


              • #37
                So, in practical terms, is btrfs good enough to be used instead of ext4? Is it stable and does it keep data correctly? Also, just out of curiosity, do we know the reasons behind the various regressions and progressions?

                Comment


                • #38
                  Originally posted by atmartens View Post
                  So, in practical terms, is btrfs good enough to be used instead of ext4? Is it stable and does it keep data correctly? Also, just out of curiosity, do we know the reasons behind the various regressions and progressions?
                  If you care about your data, not trust any new FS. btrfs isn't marked "stable" in the kernel. ext4 is "stable" but some users have had data losses. I use ext4 for my root FS (I can always use a LiveCD/USB to have a OS), but for data I use ext3.

                  Comment


                  • #39
                    The SQLite test as it stands is *very* sensitive to the fsync/fdatasync. You can tune the test to demonstrate database performance, but it currently isn't intended to do that. The intent of the test is to show the FS performance, and to simulate some contrived situations where people can't do transactions (like a busy 2-tier PHP site. The 3rd tier allows you to aggregate transactions, but a 2-tier won't)..

                    In most cases where there is a large delta, it has been shown that the "faster" FS has either traded performance for data integrity or have thrown out integrity altogether (there was a KVM/QEMU bug that mean a sync file operation would end up being async. The guest running under KVM was about 100 times faster than the host for the SQLITE test. As it turns out the fsync in the KVM, wasn't really an fsync to the physical disk anyway.
                    Exactly, my intention was not to trash on the benchmark but simply to inform people that there is a huge difference in using SQLite "properly" and not.

                    Comment


                    • #40
                      Originally posted by RussDill View Post
                      Its really too bad more people aren't finding the wiki:

                      http://btrfs.wiki.kernel.org/index.p...sion_from_Ext3
                      Awesome, thanks!

                      Comment


                      • #41
                        Re: Phoronix benchmark criticism

                        Michel,

                        I must say that I'm rather disappointed by your attitude to constructive criticism. Really, censoring out my post without any (even private) reply is really hard to understand. Despite the problems I described I thought that your aim was to contribute with something useful for the Linux community - I'm not convinced about that at all now. I'm afraid that without change of your attitude the developer part of the community cannot take your work seriously. That's a pity.

                        Comment


                        • #42
                          Ahh, interesting, this time my post doesn't wait for approval - so this is a benchmark after how long my post gets deleted - reposting my original message sent 4 days ago:

                          Michael,

                          I'm really fascinated by you "benchmarks" - in a negative way though I must admit. For instance your "infamous" sqlite insert test - what you do is a complete nonsense. Without looking at the benchmark code, I can confidentaly say that you do inserts without enclosing them in a transaction. The result is that what you benchmark is "really bad programmer's code" performance rather than something that any reasonable program would do. Of course you _would_ know this if you knew what you are doing (which is the biggest problem of your benchmarks that just show some random charts without any context). For instance, this is from SQLite FAQ:


                          (19) INSERT is really slow - I can only do few dozen INSERTs per second

                          Actually, SQLite will easily do 50,000 or more INSERT statements per second on an average desktop computer. But it will only do a few dozen transactions per second. Transaction speed is limited by the rotational speed of your disk drive. A transaction normally requires two complete rotations of the disk platter, which on a 7200RPM disk drive limits you to about 60 transactions per second.

                          Transaction speed is limited by disk drive speed because (by default) SQLite actually waits until the data really is safely stored on the disk surface before the transaction is complete. That way, if you suddenly lose power or if your OS crashes, your data is still safe. For details, read about atomic commit in SQLite..

                          By default, each INSERT statement is its own transaction. But if you surround multiple INSERT statements with BEGIN...COMMIT then all the inserts are grouped into a single transaction. The time needed to commit the transaction is amortized over all the enclosed insert statements and so the time per insert statement is greatly reduced.

                          Another option is to run PRAGMA synchronous=OFF. This command will cause SQLite to not wait on data to reach the disk surface, which will make write operations appear to be much faster. But if you lose power in the middle of a transaction, your database file might go corrupt.
                          Now look at the results of your insert benchmark - does it look familiar? I bet it does - few dozen inserts instead of tens of thousands of inserts. Is your benchmark useful? Not at all - nobody will be so stupid to do such a thing in his program. (What your benchmark does for rotational hard drives is that it measures the number of rotates per second).

                          One more example would be your article "The Performance Of EXT4 Then & Now" which was supposed to demonstrate how the performance of ext4 evolved. Well, you did _not_ measure that at all. The fact that some disk benchmark is slower under kernel A than kernel B doesn't mean that it's because of ext4 - there have been quite dramatic changes in IO scheduler towards lower latency, which I think is the main cause of the performance changes. Also the per BDI flusher threads had definitely significant impact on IO performance. See 1.1 and 1.5 here

                          http://kernelnewbies.org/Linux_2_6_32

                          ext4 is relatively stable and there are not many changes these days that would influence performance dramatically. However, 2.6.33 contains a large number of CFQ changes, which I'm quite sure contribute to performance differences in benchmarks much more than the modifications of filesystems.

                          If you want to get filesystem performance history, you should take several filesystems (ext3, ext4, XFS, reiser) and measure their performance for all the kernel version. If all of them have some performance in kernel version A and lower performance in kernel version B, the reason will most probably be that something else than the filesystem has changed that influenced the performance (e.g. IO scheduler) [Of course, some IO scheduler change can influence one filesystem more than the other filesystem so this is not very exact either]. Now concerning the performance drop between 2.6.30 and 2.6.31 - are you sure that Ubuntu didn't start using CFQ scheduler then instead of anticipatory IO scheduler? (I really don't know - just a wild guess, probably totally wrong. What I want to say is that when you perform a benchmark, you do it for the whole kernel - and there are pretty many things that might influence the result.)

                          I'm really sorry if I sound too offensive but I just can't understand your attitude to the benchmarking. Less is more sometimes. Instead of having tens of more or less garbage benchmarks a few benchmarks where you know what you are doing and where you can interpret the results somehow is _much_ more useful. It's a real pity - I can imagine you spend a lot of time by preparing everything for your web page but the result is something that nobody can take seriously. How about re-prioritising your work and start learning what you are doing? ;-)

                          Comment


                          • #43
                            Aha, got it - when the post is short enough, is doesn't wait for moderator's approval. Good.

                            For those who are interested, I was pointing at the SQLite "benchmark" that benchmarks just a wrong use of SQLite - see

                            http://www.sqlite.org/faq.html

                            point 19 - there should be tens of thousands inserts per second when using a single transaction - no reasonable program will use SQLite in the way as Michael does. Another point was that in his previous test of "The Performance Of EXT4 Then & Now" didn't test just ext4, but the whole kernel - and there were quite some changes in the IO scheduler recently, so I seriously doubt that the performance changes can be attributed to ext4 only and Michael conclusions are plain wrong. And finally I pointed out that Michael should understand to what he is doing, which I guess lead to erasing my post...

                            Comment


                            • #44
                              Originally posted by teekee View Post
                              Michel,

                              I must say that I'm rather disappointed by your attitude to constructive criticism. Really, censoring out my post without any (even private) reply is really hard to understand. Despite the problems I described I thought that your aim was to contribute with something useful for the Linux community - I'm not convinced about that at all now. I'm afraid that without change of your attitude the developer part of the community cannot take your work seriously. That's a pity.
                              Censoring? There's no censoring. There's spam filters. You have a post count of just two and when your posts contain links they go into a moderation queue until cleared. Your posts should now be live.
                              Michael Larabel
                              http://www.michaellarabel.com/

                              Comment


                              • #45
                                OK, then sorry for what I've written. Just to clarify, I wrote the original post (the long one) 4 days ago and it just disappeared.

                                But as you say, it was probably just a too active spam filter. Once again sorry for accusing you of censoring - I just incorrectly thought that critical voices aren't allowed here.

                                Comment

                                Working...
                                X