Announcement

Collapse
No announcement yet.

Linux 3.14 File-System HDD Benchmarks

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

  • Linux 3.14 File-System HDD Benchmarks

    Phoronix: Linux 3.14 File-System HDD Benchmarks

    Early Linux 3.14 kernel benchmarks indicated there might be some slowdowns in disk/file-system performance for this next major kernel release. That early testing was done from an Intel ultrabook with solid-state drive while we're now in the process of carrying out more focused testing of Linux 3.14 on both HDDs and SSDs. In this article are our first hard drive benchmarks from the Linux 3.14 Git kernel compared to the stable 3.12 and 3.13 kernels.

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

  • #2
    Is it possible to have some boot speed benchmarks too?

    And is Btrfs ready for daily use without the fear of data loss?

    Comment


    • #3
      Originally posted by siavashserver View Post
      And is Btrfs ready for daily use without the fear of data loss?
      I've been using Btrfs daily on my main machine and my HTPC for years now. Not only have I not lost any data, but its snapshot features have saved my data numerous times (last time being around a week ago when I tried to uninstall the NVIDIA blob installed from the run script, which still leaves behind symlinks that completely stop X from starting; restore a snapshot before installing the blob and everything's back to normal).

      And speaking of Btrfs, I updated my Snapper ebuilds for Gentoo Sunrise. They're still pending review, but will probably be accepted and uploaded soon enough (in the mean while they're on the bug tracker).

      Comment


      • #4
        Originally posted by GreatEmerald View Post
        I've been using Btrfs daily on my main machine and my HTPC for years now. Not only have I not lost any data, but its snapshot features have saved my data numerous times (last time being around a week ago when I tried to uninstall the NVIDIA blob installed from the run script, which still leaves behind symlinks that completely stop X from starting; restore a snapshot before installing the blob and everything's back to normal).

        And speaking of Btrfs, I updated my Snapper ebuilds for Gentoo Sunrise. They're still pending review, but will probably be accepted and uploaded soon enough (in the mean while they're on the bug tracker).
        Have you ever used btrfsck?

        - Gilboa
        DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB + 2x3TB, GTX780, F21/x86_64, Dell U2711.
        SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F21/x86_64, Dell U2412..
        BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F21/x86-64.
        LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F21/x86_64.

        Comment


        • #5
          Originally posted by siavashserver View Post
          And is Btrfs ready for daily use without the fear of data loss?
          I've been using Btrfs on my laptop's SSD since Fedora 17, my home server / HTPC's main drive and its backup drive for the last few months, so far no random problems on any of them. The ONE failure I have had was related to power-loss during a system update like a year and a half ago (200+ updates and the power got killed, accidentally, during I think the kernel update)

          Is my single use-case a perfect "yes! Use it!"? No, but I personally trust it more on the backup drive than I do NTFS-over-fuse quite frankly

          Comment


          • #6
            I never had issue's with BTRFS as well. But I did only start using it from the start of january this year.

            Twice I had this weird OOPS during boot on an old 32bit UP machine.

            Comment


            • #7
              @ GreatEmerald , Ericg

              Thank you both for sharing, I'm going to try it with a fresh install on one of machines For the main machine, is converting existing ext4 partitions to btrfs a safe operation? Or should I backup data and go with a fresh install?

              Comment


              • #8
                Originally posted by gilboa View Post
                Have you ever used btrfsck?
                Yes. In fact, I have a LiveCD build on SUSE Studio just for that (it automatically pulls in the latest kernel and btrfs tools for performing complex offline tasks; last time I used it to set up a backup in a different drive using btrfs-send/btrfs-receive). The btrfs check tool itself I usually run regularly to see if it reports any problems. There sometimes are some problems when I have to force-poweroff the machine (like when the GPU hangs), but they usually amount to some warnings and some data truncation. The former are mostly solved by running btrfs scrub. There was a case when it didn't help, and I needed to run the btrfs check repair to solve those. (There was also a time when btrfs check reported a lot of false positives, and even the warnings emitted now generally don't amount to much the developers themselves can't tell what some of them are about without having direct access to the drive in question). There was also one time some years ago when I had bad RAM, which caused corruption that btrfs check repair couldn't solve either, but that's pretty much a given (and I still was able to retrieve all the data I needed).

                But yes, in general, it's a good idea to run btrfs check regularly to see if there are any issues reported, also regularly check the btrfs gotchas page ( https://btrfs.wiki.kernel.org/index.php/Gotchas one thing that is not mentioned there yet is that 3.11.10 also solves the latter balance issue) for any information on the issues in the latest FS issues, and when in doubt, go over to #btrfs on freenode and ask there.

                Originally posted by Rexilion View Post
                I never had issue's with BTRFS as well. But I did only start using it from the start of january this year.

                Twice I had this weird OOPS during boot on an old 32bit UP machine.
                Yea, I did hit some corner-case oopses last year as well, but those are usually fixed rather quickly and so upgrading to the latest kernel usually solves it.

                Originally posted by siavashserver View Post
                For the main machine, is converting existing ext4 partitions to btrfs a safe operation? Or should I backup data and go with a fresh install?
                Well, I never really tried it myself. Though it should be safe (once again, when in doubt, ask in #btrfs). Mind you, even if it is safe, converting is never optimal, and you're always better off doing a clean install. Besides, it's a good motivation to clean up your data

                For one, right now I'm waiting for 3.14 to be released, so I could use bcache with Btrfs with my new SSD (at the moment I'm just using metadata RAID 1 between my HDD and SSD all set up in online mode). Using bcache will require reformatting the whole thing, and by the time 3.14 is out, I'll have accumulated enough cruft for it to be worth it if only to clean up the disk and make a backup.

                Comment


                • #9
                  testing on hybrid drives

                  I'm a bit afraid that testing on hybrid drives may give false results, because they are so unpredictable. The difference in performance may easily be 10-fold or more depending on what the drive decides to cache. I've seen cases where one day a system boots 15 seconds, and the next day it takes 3 minutes.

                  Small differences in models and firmware versions may give big advantages to some file systems / access patterns while heavily penalizing others. I wouldn't be surprised if NTFS was the fastest filesystem ever on such a drive, just because the drive was optimized for it.

                  Additionally, I don't think there is a way to clean that cache between test runs, and when testing one filesystem after the other, it may take time for the drive to notice that the hot zone to cache moved to a different place, at least in theory.

                  I wonder how it is in practice. It would be an interesting project to test behavior of various hybrid drives more thoroughly.

                  Comment


                  • #10
                    to be fair the behavior is consistent across file systems and kernels over multiple runs, so i don't think it would be a problem(caching and whatnot)

                    Can we have a standard hd test as well? I was very suprised by the results for btrfs, they really picked up the performance speed here.

                    Comment


                    • #11
                      I'd hapily switch to Btrfs or even ext4+LVM but it would mean giving up my problem-free, beginner-friendly backup solution which is CloneZilla. There are few problems with LVM one can stumble upon in a completely standard scenario. Does Btrfs similarly bring difficulties for CloneZilla users?

                      Or, alternatively, can Btrfs features replace CloneZilla as far as backup goes? Full disk backups capability is a must (including GPT Bios boot partition, /boot partition).

                      Comment


                      • #12
                        Originally posted by sireangelus View Post
                        Can we have a standard hd test as well? I was very suprised by the results for btrfs, they really picked up the performance speed here.
                        I agree - btrfs is normally slower than ext4, and I say that as someone who uses it on all my systems. It could be that btrfs benefits greatly from SSD caching, which means it'll go great with bcache once the latter is more stable.

                        Comment


                        • #13
                          Originally posted by Bucic View Post
                          I'd hapily switch to Btrfs or even ext4+LVM but it would mean giving up my problem-free, beginner-friendly backup solution which is CloneZilla. There are few problems with LVM one can stumble upon in a completely standard scenario. Does Btrfs similarly bring difficulties for CloneZilla users?

                          Or, alternatively, can Btrfs features replace CloneZilla as far as backup goes? Full disk backups capability is a must (including GPT Bios boot partition, /boot partition).
                          I'm not sure what CloneZilla does, exactly, but Btrfs has LVM features; yet they, naturally, work only in Btrfs partitions. For instance, the UEFI system partition must be FAT32, there is no way around that. And the swap partition must also be a real swap partition (Btrfs doesn't support swapfiles). There are no problems with /boot being a part of the Btrfs partition, though (that's how I have mine set up).

                          But about backups, there are several things Btrfs supports there. First off is snapshots cheap to make, yet complete subvolume copies thanks to copy-on-write. Snapper makes them and cleans them automatically with a cron job. YaST and zypper also make pre/post snapshots automatically, too, to allow you to both check what was changed during the session and to roll back changes. On Gentoo I have made a script for myself that creates pre/post snapshots on every non-pretend invocation of emerge for the same reason.

                          Next we have RAID, of course. Btrfs generally best supports simple mirroring (RAID5/6 are still being worked on IIRC), so that if you have two disks, if one suddenly dies you still have the other with the exact same data (and/or metadata, RAID applies to those independently; very useful in my case, where I have a small SSD and a large HDD I couldn't mirror the whole HDD contents on the SSD, but I did it with the metadata, and still have space for new data on the SSD).

                          And then you have btrfs send/receive, which can copy a subvolume/snapshot to another device, and also synchronise it once the original changes (without recopying the entire thing), which means that you can have manual backups on external storage that way. These copies are accessible like any other regular Btrfs file system (except they're by default read-only). So if you want to do something potentially dangerous and want to make a manual full backup, this is the way to go.

                          Comment


                          • #14
                            I just wonder if this benchmark is really about file-system performance or which file-system works best with the caching algorithm of this hybrid drive. Would be nice to see numbers for real HDDs and SSDs. to rule out such a possibility.

                            Comment


                            • #15
                              Originally posted by GreatEmerald View Post
                              I'm not sure what CloneZilla does, exactly, but Btrfs has LVM features; yet they, naturally, work only in Btrfs partitions. For instance, the UEFI system partition must be FAT32, there is no way around that. And the swap partition must also be a real swap partition (Btrfs doesn't support swapfiles). There are no problems with /boot being a part of the Btrfs partition, though (that's how I have mine set up).

                              But about backups, there are several things Btrfs supports there. First off is snapshots cheap to make, yet complete subvolume copies thanks to copy-on-write. Snapper makes them and cleans them automatically with a cron job. YaST and zypper also make pre/post snapshots automatically, too, to allow you to both check what was changed during the session and to roll back changes. On Gentoo I have made a script for myself that creates pre/post snapshots on every non-pretend invocation of emerge for the same reason.

                              Next we have RAID, of course. Btrfs generally best supports simple mirroring (RAID5/6 are still being worked on IIRC), so that if you have two disks, if one suddenly dies you still have the other with the exact same data (and/or metadata, RAID applies to those independently; very useful in my case, where I have a small SSD and a large HDD I couldn't mirror the whole HDD contents on the SSD, but I did it with the metadata, and still have space for new data on the SSD).

                              And then you have btrfs send/receive, which can copy a subvolume/snapshot to another device, and also synchronise it once the original changes (without recopying the entire thing), which means that you can have manual backups on external storage that way. These copies are accessible like any other regular Btrfs file system (except they're by default read-only). So if you want to do something potentially dangerous and want to make a manual full backup, this is the way to go.
                              Nicely laid out, thanks.

                              I know that Btrfs 'has LVM '. That's why I said 'Ext4+LVM or Btrfs'.

                              However, what puts me off as a beginner is this 'snapshot everything'. For me a zero-zero restore, i.e. ability to restore to a completely wiped-out disk from a backup, is what I need to establish first and foremost. So:
                              1. Does Btrfs have this ability out of the box (no workarounds/hacks)?
                              OR
                              2. Is there a Clonezilla alternative that handles Btrfs in a hassle-free manner?

                              Comment

                              Working...
                              X