Announcement

Collapse
No announcement yet.

Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10

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

  • #16
    Originally posted by Ericg View Post
    From what I hear, XFS is very prone to complete failures and even one dirty shutdown can hose the entire system. -
    A possibility, yes, prone, I wouldn't says so. In 15 years I have yet to actually come across any corruption or failures using XFS and trust me, there have been quite a few dirty shutdowns. I've actually had more issues with data integrity with EXT 3 then with XFS.

    Comment


    • #17
      Originally posted by Ericg View Post
      Ext4's architecture and design is 20years old, its boilerplate code atop ext1. Thats about as much of a "hackjob" as you can get. So tell me.. do you like the thought of your entire filesystem being a hack job?

      Besides, every filesystem has its own place and own goal. F2F2 is designed or flash media like phones and tablets. Btrfs is a pretty good general filesystem, especially if have limited space (compression) or multiple disks (built in volume management), it also has functions specifically built in for ssd's which is very relevent in the future, something that ext4 doesn't have.

      XFS, JFS, Reiser, those..I honestly couldn't tell you what they are good for. From what I hear, XFS is very prone to complete failures and even one dirty shutdown can hose the entire system. JFS was an IBM filesystem from forever ago, Reiser was a proof-of-concept filesystem who's reputation got trashed after its head developer (and the person it was named after) murdered his wife.

      What I am looking forward to though is Tux3, It will be very interesting to see the results of Tux3 vs Btrfs in the next few years.

      --A happy btrfs user--
      I'm really happy with btrfs also. I know SSD's are all the rage these days but I also have older hard disks for storage and BTRFS w/LZO makes a huge difference on rotational disks. I can't tell a big difference with LZO on my SSD but its great on my other disks. BTRFS's native snapshot ability sounds great too but I've not used it yet.

      Comment


      • #18
        BTRFS is slow as ****

        So let me see... BTRFS is slower than EXT4 pretty much everywhere, sometimes MUCH slower. All the purported features of BTRFS that are supposed to make BTRFS better are pie-in-the-sky as far as I can tell. Has anyone actually used the BTRFS snapshot thing on their Linux Desktop? Is there even a GUI for it, something that can come close to Apple's Time Machine? From a Linux Desktop user's perspective, BTRFS is worthless right now, and development resources going into it are a waste.

        As for compression, I'm sorry, but I don't want to waste CPU and get latency because the underlying filesystem sucks at arranging data on the hard disk.

        Comment


        • #19
          Originally posted by stan View Post
          So let me see... BTRFS is slower than EXT4 pretty much everywhere, sometimes MUCH slower.
          I don't know, it looked pretty competitive in most tests. There were just some where it was way slower.

          All the purported features of BTRFS that are supposed to make BTRFS better are pie-in-the-sky as far as I can tell. Has anyone actually used the BTRFS snapshot thing on their Linux Desktop? Is there even a GUI for it, something that can come close to Apple's Time Machine?
          Yes, it works well. No, there's no fancy GUI, but the underlying tech works fine.

          As for compression, I'm sorry, but I don't want to waste CPU and get latency because the underlying filesystem sucks at arranging data on the hard disk.
          Compression results in LESS latency, because the CPU can decompress things faster than IO can read data from a disk.

          Comment


          • #20
            Originally posted by Ericg View Post
            True, wasn't thinking about the fact that he just does zero-filled files instead of random-filled
            Off-topic: From a merely theoretical standpoint, is there any benefit in (losslessly) compressing truly random data?

            Comment


            • #21
              Originally posted by IsacDaavid View Post
              Off-topic: From a merely theoretical standpoint, is there any benefit in (losslessly) compressing truly random data?
              If it's "truly random" then there is no pattern, and can not be any way to compress it.

              However, most data on a computer is not truly random. Text files and executable files are generally highly compressible. So is uncompressed video, but if you've already used a lossy compressor like mp3/h264/etc., then it's tough to do much more to it.

              A proper compressing filesystem should be able to detect when the data is compressible and when it should be skipped, and allow you to automatically take advantage of the feature only when it's actually beneficial.

              Comment


              • #22
                Originally posted by smitty3268 View Post
                If it's "truly random" then there is no pattern, and can not be any way to compress it.

                However, most data on a computer is not truly random. Text files and executable files are generally highly compressible. So is uncompressed video, but if you've already used a lossy compressor like mp3/h264/etc., then it's tough to do much more to it.

                A proper compressing filesystem should be able to detect when the data is compressible and when it should be skipped, and allow you to automatically take advantage of the feature only when it's actually beneficial.
                Btrfs does if you just do compress=(algorithm), it auto skips photos, music, videos and anything else that it sees as not easily compressed. If you want it to try anyway then there's a different mount option for that.

                Comment


                • #23
                  Originally posted by stan View Post
                  So let me see... BTRFS is slower than EXT4 pretty much everywhere, sometimes MUCH slower. All the purported features of BTRFS that are supposed to make BTRFS better are pie-in-the-sky as far as I can tell. Has anyone actually used the BTRFS snapshot thing on their Linux Desktop? Is there even a GUI for it, something that can come close to Apple's Time Machine? From a Linux Desktop user's perspective, BTRFS is worthless right now, and development resources going into it are a waste.

                  As for compression, I'm sorry, but I don't want to waste CPU and get latency because the underlying filesystem sucks at arranging data on the hard disk.
                  Features that make btrfs better than Ext4...

                  1) Built in compress
                  2) deduplication is being worked on
                  3) built in volume manager
                  4) ability to detect even single-bit corruption
                  5) integrity checking the ext4 can never even DREAM of getting.
                  6) ssd optimizations
                  7) snapshotting
                  8) online resizing
                  9) online defragging
                  10) Almost all raid levels supported in filesystem

                  The only one the is even REMOTELY "Pie in the sky" is dedup, and its in progress. As far as your comment about compression... if you have a modern CPU then the compression takes less an millisecond except for gigantic files, which would most likely be video files...which it auto-skips on compression anyway, so you're getting zero latency. Also the data takes up less space on disk (important for early SSD adopters like me who only have 128GB ssd's in their laptops), and can be written TO disk more quickly since more data can be fit into the buffer.

                  The snapshotting feature doesn't have a GUI yet, no, but its tech is stable and its being used on Suse and Fedora to integrate into update managers (same way windows does updates: create a snapshot before the update, update, if it breaks then you roll back to that pre-update snapshot).

                  Is Btrfs slower than Ext4? Possibly. Though I'm not even positive it IS since we all know Michael's tests dont measure real-world performance (writing zeros to files doesnt count) but I don't even feel it or notice it on my laptop and I did a re-install to switch over to btrfs. The development efforts DEFINITELY aren't a waste, and I am looking forward to the day that either Btrfs or Tux3 replace Ext4.

                  Quite honestly Stan you just look like a troll at this point, and a really bad one at that.

                  Comment


                  • #24
                    A lot of people worry about compression and the latency or CPU load that might come with it. However, one of the most CPU intensive workloads that I do is compiling very large projects(Chromium, Android, etc), these keep CPU usage pegged at 100% on all cores nearly the whole time yet it is faster with BTRFS compression than without. One caveat is that you need to use LZO rather than ZLIB. It is slightly faster with compression on my SSD and much faster if the compilation is done on a rotational hard disk.

                    Originally posted by Ericg View Post
                    Features that make btrfs better than Ext4...

                    1) Built in compress
                    2) deduplication is being worked on
                    3) built in volume manager
                    4) ability to detect even single-bit corruption
                    5) integrity checking the ext4 can never even DREAM of getting.
                    6) ssd optimizations
                    7) snapshotting
                    8) online resizing
                    9) online defragging
                    10) Almost all raid levels supported in filesystem

                    The only one the is even REMOTELY "Pie in the sky" is dedup, and its in progress. As far as your comment about compression... if you have a modern CPU then the compression takes less an millisecond except for gigantic files, which would most likely be video files...which it auto-skips on compression anyway, so you're getting zero latency. Also the data takes up less space on disk (important for early SSD adopters like me who only have 128GB ssd's in their laptops), and can be written TO disk more quickly since more data can be fit into the buffer.

                    The snapshotting feature doesn't have a GUI yet, no, but its tech is stable and its being used on Suse and Fedora to integrate into update managers (same way windows does updates: create a snapshot before the update, update, if it breaks then you roll back to that pre-update snapshot).

                    Is Btrfs slower than Ext4? Possibly. Though I'm not even positive it IS since we all know Michael's tests dont measure real-world performance (writing zeros to files doesnt count) but I don't even feel it or notice it on my laptop and I did a re-install to switch over to btrfs. The development efforts DEFINITELY aren't a waste, and I am looking forward to the day that either Btrfs or Tux3 replace Ext4.

                    Quite honestly Stan you just look like a troll at this point, and a really bad one at that.

                    I don't think he's a troll. I think his view is actually the current popular consensus even if I disagree with it.

                    Comment


                    • #25
                      I've been back on btrfs since the 3.8 Kernel, and don't think I'll be switching to anything else. It's fairly quick with the recent updates, and I use the snapshotting ALL the time.

                      Comment


                      • #26
                        Just to note, I have been using btrfs as an alternate backup for my core system (about 80g) for over a year. I
                        rsync to the partition and snapshot that twice a month. Currenly, using compression, the btrfs is upto 120g, and
                        contains 38 snapshots named by date. I have already found this 'time machine' useful for recovering data. I also
                        have another btrfs partition mostly full of large video files. This machine has been killed by brownouts many
                        times. So far, everything is working well. I still use ext4 for most of my filesystems, but I consider btrfs worthy
                        of consideration. Particularly if I was going to use raid or volume management. Oh, this is a Gentoo box, so that
                        core filesystem changes *a lot*, so those 38 snapshots are not trivial.

                        Comment


                        • #27
                          Originally posted by Ericg View Post
                          True, wasn't thinking about the fact that he just does zero-filled files instead of random-filled
                          in case of random filled file it would be better for brtfs WITHOUT compression!

                          purely random data cannot be compressed.

                          Comment


                          • #28
                            Originally posted by set135 View Post
                            Just to note, I have been using btrfs as an alternate backup for my core system (about 80g) for over a year. I
                            rsync to the partition and snapshot that twice a month. Currenly, using compression, the btrfs is upto 120g, and
                            contains 38 snapshots named by date. I have already found this 'time machine' useful for recovering data. I also
                            have another btrfs partition mostly full of large video files. This machine has been killed by brownouts many
                            times. So far, everything is working well. I still use ext4 for most of my filesystems, but I consider btrfs worthy
                            of consideration. Particularly if I was going to use raid or volume management. Oh, this is a Gentoo box, so that
                            core filesystem changes *a lot*, so those 38 snapshots are not trivial.
                            You might look into experimenting with send/receive using btrfs. I imagine it'd be way more efficient than using rsync

                            Comment


                            • #29
                              Originally posted by stan View Post
                              So let me see... BTRFS is slower than EXT4 pretty much everywhere, sometimes MUCH slower. All the purported features of BTRFS that are supposed to make BTRFS better are pie-in-the-sky as far as I can tell. Has anyone actually used the BTRFS snapshot thing on their Linux Desktop? Is there even a GUI for it, something that can come close to Apple's Time Machine? From a Linux Desktop user's perspective, BTRFS is worthless right now, and development resources going into it are a waste.
                              Are you serious? I can't live without snapshots. And yes, there is a GUI tool for snapshots, it's called Snapper. Though it needs YaST for its GUI; otherwise, it's a CLI utility. It also does automatic snapshotting and can show the differences between files in different snapshots.

                              Originally posted by set135 View Post
                              Oh, this is a Gentoo box, so that core filesystem changes *a lot*, so those 38 snapshots are not trivial.
                              About Gentoo, I made an ebuild for Snapper, it's currently on Sunrise. You probably could use it, makes creating snapshots super easy. On my Gentoo machine, I made a "bmerge" script that makes a pre-post snapshot for every emerge process, so you can very easily do a perfect unmerge that way.

                              Comment


                              • #30
                                I've been reading many positive critics about btrfs for a couple years and how this promising filesystem is supposed to eventually replace ext4, but after all this time I must admit those benchmarks feel a bit daunting, specially the compilation and database ones. Do you think btrfs will ever get near the speed of ext4, or is it that all those fancy features come at a performance cost?

                                I'm also waiting for swap file support.

                                Comment

                                Working...
                                X