Announcement

Collapse
No announcement yet.

The Linux 2.6.37 Kernel With EXT4 & Btrfs

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

  • The Linux 2.6.37 Kernel With EXT4 & Btrfs

    Phoronix: The Linux 2.6.37 Kernel With EXT4 & Btrfs

    Now that the Linux 2.6.37 kernel merge window is closed and this next major release is in the middle of its development cycle, we have new benchmarks to publish looking at the file-system performance of Btrfs and EXT4 compared to earlier releases. The Linux file-system performance is under constant evolution as shown by our five years of Linux kernel benchmarks and more recent file-system-focused articles such as looking at EXT4 and Btrfs regressions in Linux 2.6.36, solid-state drive Linux benchmarks, and even ZFS-FUSE benchmarks, among other similar articles.

    http://www.phoronix.com/vr.php?view=15438

  • #2
    Is it possible to ever get any analysis?

    Comment


    • #3
      Originally posted by jbrown96 View Post
      Is it possible to ever get any analysis?
      Nope, just lots of graphs with text underneath describing the graphs for the visually impaired - clearly for the users of Festival

      Comment


      • #4
        I don't read the text anyway. The only thing I was interested in was in the beginning, where the testing system was described. The rest I can analyze myself.

        Comment


        • #5
          Test Environment

          Hi Phoronix,

          I was wondering how you setup your test environment when running filesystem tests. I assume you simple reformat the partition for each test, thus allowing the test to start in a clean, consistent environment.

          Although that method should produce the most consistent results it does not take into account normal usage of the filesystem. For example, on my computer my /usr partition is about 16G and usage is at 50%. Every few months I basically rewrite all the data to that partition. Resulting from this usage I expect there to be a fairly high amount of fragmentation of files.

          In the above situation it is unlikely that the filesystem will find continuous space for big files and for there to be a reduction in performance. At Anandtech a similar principle applied to SSDs resulting in a performance degradation between 40% to 95%.

          The Anandtech article is at:
          http://www.anandtech.com/show/2738
          with the comparison of performance:
          http://www.anandtech.com/show/2738/13

          Would it be possible to test filesystems that are at various levels of use (i.e. 50%-90%) after multiples of data being written to them (i.e. on a 20G drive extract FreeBSD sources 40x [sources are ~0.5G], and removing old sources when usage exceeds given level, i.e. simulate normal usage, wear and tear).

          Regards

          Comment


          • #6
            What about RAID?

            I don't know how popular RAID is for most readers of Phoronix, but for me "Desktop performance" means RAID5 with 3-4 HDDs, so I would be more interested in seeing how various filesystems / kernel versions scale on this kind of a setup.

            Comment


            • #7
              Given that opensuse 11.4 is almost certain to ship with 2.6.37, is it likely that BTRFS will be a fefault install option for this distro release?

              Is it stable/fast enough to be included in the installer as a selectable (non warning) option?

              cheers

              Comment


              • #8
                Originally posted by R3MF View Post
                Given that opensuse 11.4 is almost certain to ship with 2.6.37, is it likely that BTRFS will be a fefault install option for this distro release?

                Is it stable/fast enough to be included in the installer as a selectable (non warning) option?

                cheers
                You might have to wait till 2.6.38 I presume to ensure that it is indeed stable enough to be used as a selectable default install option.

                In my own opinion I'd like to have an ENTIRE root partition as btrfs with /boot on / though, so may have to wait longer till even GRUB can actually boot directly from btrfs filesystems. Ext4 is fast catching up in performance so then you'd have some great filesystem choices :^)

                Comment


                • #9
                  cheers.

                  opensuse split boot and home into different partitions, does this make it more likely they'd allow btrfs as a non-warning option?

                  Comment


                  • #10
                    Originally posted by DragonSA View Post
                    I was wondering how you setup your test environment when running filesystem tests. I assume you simple reformat the partition for each test, thus allowing the test to start in a clean, consistent environment.

                    Although that method should produce the most consistent results it does not take into account normal usage of the filesystem. For example, on my computer my /usr partition is about 16G and usage is at 50%. Every few months I basically rewrite all the data to that partition. Resulting from this usage I expect there to be a fairly high amount of fragmentation of files.

                    In the above situation it is unlikely that the filesystem will find continuous space for big files and for there to be a reduction in performance.Regards
                    Without taking this into account these kind of "benchmarks" are completely useless nonsense.

                    Comment


                    • #11
                      I wonder how the benchmark would look if the new 'space_cache' mount option were used (available in the new 2.6.37 kernel) for btrfs.

                      Comment


                      • #12
                        Originally posted by renkin View Post
                        I wonder how the benchmark would look if the new 'space_cache' mount option were used (available in the new 2.6.37 kernel) for btrfs.
                        I've done some benchmarks on Btrfs with Linux 2.6.37-rc3, space_cache helps a lot!

                        See http://mupuf.org/blog/article/41/

                        Comment

                        Working...
                        X