Announcement

Collapse
No announcement yet.

Linux 3.3 Kernel: Btrfs vs. EXT4

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

  • #11
    Originally posted by fackamato View Post
    .. which is not visible to the filesystem, so compression still matters a lot.
    It's not visible to the file system, but if you have a SF controller you shouldn't run filesystem level compression b/c it's superfluous. At best you may save a bit of space, but it will, in all cases, slow down your ops.
    What is it I'm missing?

    Comment


    • #12
      Any upcoming benchmark with transparent FS compression on Phoronix ?

      Comment


      • #13
        Any upcoming benchmark with transparent FS compression on Phoronix ?
        I'm sure that the data already exists to a usable degree. Does anyone know how to sort/filter OB to show btrfs results with compression?

        OpenBenchmarking.org, Phoronix Test Suite, Linux benchmarking, automated benchmarking, benchmarking results, benchmarking repository, open source benchmarking, benchmarking test profiles


        It would be nice to compare http://openbenchmarking.org/result/1...AR-BTRFSLZ4124 with http://openbenchmarking.org/result/1...BY-LINUX33BT16 and others in a single window and not have to switch between tabs.


        F
        Last edited by russofris; 03 March 2012, 12:04 PM.

        Comment


        • #14
          Originally posted by mayankleoboy1 View Post
          I am disappointed by the stock performance of BTRFS. It has been said to be the next standard linux file system and it cant compete with ext4.
          Is transparent compression the only saving grace of BTRFS?
          I don't see why you should be. At least not from these benchmarks. These benchmarks are artificial and only show very specific aspects of the file system... most of which is almost entirely irrelevant to most people's use cases. They really likely have very little bearing on what it is going to be like to run them in your desktop or a production system.

          The principal advantage that Ext4 is going to have is that some of it's code is decades old and has hundred's of man-hours poured into it's development. It is very mature and there is very little that is going to surprise you with it and best practices are well established and widely known.

          Btrfs on the other hand is going to require years of in-field usage and wide scale deployment before it can compete with Ext4 with that. But what Btrfs offers is significantly enhanced ability to manage data and from a administrative standpoint this is going to be invaluable once people learn to take advantage of it.

          .. which is not visible to the filesystem, so compression still matters a lot.
          Maybe, maybe not.

          Most data people care about performance nowadays is already heavily compressed. If you care about, say, your ability to use Linux to manage multimedia files then compression is utterly irrelevant on the file system level and on the controller level. They use format-specific compression techniques and the chances of file system compression helping out is _NONE_AT_ALL_.

          Now if you are dealing with thousands of plain text files ranging in size from 2MB to multiple GBs then compression is something that is probably going to matter a lot to you. That is, of course, you are not already using gzip or whatever to compress your data.

          Comment


          • #15
            Originally posted by fackamato View Post
            .. which is not visible to the filesystem, so compression still matters a lot.
            The Sandforces compress all data they write, and reaching their advertised performance/endurance depends on the data written to them to be compressible. If you compress your data before that, you interfere with the controller doing its job properly, and waste the cpu cycles needed for filesystem compression.

            Comment


            • #16
              Originally posted by liam View Post
              It's not visible to the file system, but if you have a SF controller you shouldn't run filesystem level compression b/c it's superfluous. At best you may save a bit of space, but it will, in all cases, slow down your ops.
              What is it I'm missing?
              Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.

              Comment


              • #17
                Originally posted by fackamato View Post
                Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.
                Except that on a Sandforce SSD, when it does save noticeable amounts of space, it will have a noticeable performance impact.

                Comment


                • #18
                  Originally posted by AnonymousCoward View Post
                  Except that on a Sandforce SSD, when it does save noticeable amounts of space, it will have a noticeable performance impact.
                  Why won't it save space? I'm not saying you're wrong, I just don't understand it. Example:

                  100GB SF SSD, 1 single btrfs partition. So let's say ~95GB or so available to the user. If the user writes 95GB of iso files with no compression, the performance while writing will be good and he'll use the entire filesystem.
                  If he choses to mount the filesystem with some compression option (lzo or something as fast) then the write performance will suffer a bit (at ~ 500MB/s, who cares? It's a tradeoff I guess.), but the user will still have some free space on the file system, depending on how good lzo is at compressing these ISO images. Therefore, the user can store more data than the SSD is physically capable of.

                  Comment


                  • #19


                    oh look, btrfs a lot faster than ext4 in a real world example.

                    Comment


                    • #20
                      Originally posted by fackamato View Post
                      Since SSDs are tiny, I don't mind having compression enabled sometimes saving ~50% of space on a filesystem, with non-noticeable performance impact.
                      with an SF controller who does compression you do not gain any space - but you are wearing the SSD down if you compress the data. Because the controller will not be able to compress it further, defeating one of the wear leveling mechanism.

                      Comment

                      Working...
                      X