Announcement

Collapse
No announcement yet.

Why SUSE Likes The Btrfs File-System

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

  • #11
    Originally posted by uid313 View Post
    Would be really nice to see these snapshotting capabilities of Btrfs come to Debian (apt, apt-get, synaptic, aptitude) too...
    There is "apt-btrfs-snapshot" which I use(d) on Ubuntu. I'm not sure if it's in the Debian repositories, but it works well. I think the only requirement is that your /root must be in a subvolume named "@".

    Comment


    • #12
      I'm currently using EXT4 for my root partition and for my storage I am using ZFS in a RAIDZ2 array of 4 disks. I must admit it took a while to get my head around ZFS but now I am really liking it, even have a partition of the SSD set up as cache which is working great unlike when I tried the various cache options for EXT4 that just ended badly.

      Comment


      • #13
        Originally posted by macemoneta View Post
        We've been running btrfs on multiple systems (desktops and server) in multiple configurations (single, raid0, raid1). After 15 months, we haven't encountered any issues.

        I think where people get into trouble with btrfs is that if their system experiences a problem (e.g., power outage), their first thought is to run btrfsck. However, btrfsck is the last thing you should try. The first thing is to just let btrfs resolve any issues on its own; much of the fsck functionality occurs at mount. If that doesn't work, mount with the '-o recovery' option. That lets btrfs go back in time, trying previous filesystem tree roots until it finds one with integrity. You may lose the last few seconds of changes, but your data will be intact.

        In fact, btrfs saved me when an external drive was silently corrupting data (hardware fail). Since btrfs checksums data blocks, it reported the issue. SMART indicated no problem with the drive, but in fact it was writing trash. I previously had EXT4 on the drive, and it was silent. The backups I was writing to it were worthless, but until I converted to btrfs I didn't know there was an issue.
        15 months eh? You can't be using it for anything serious then. I tried it a year ago, and it was still ridiculous slow on certain operations, some of them triggered on common stuff like apt-get. The issue only got resolved recently, until then btrfs was effectively USELESS on any Debian based linux distributions.

        I stopped using it after I got a corrupted sector and btrfs correctly reported it. Their fsck could also report it. BUT NOTHING COULD FIX IT!!!! I ended up losing more than half of the data on the drive because it was corrupted and there exists no tools to fix errors on btrfs.

        Comment


        • #14
          Originally posted by carewolf View Post
          15 months eh? You can't be using it for anything serious then. I tried it a year ago, and it was still ridiculous slow on certain operations, some of them triggered on common stuff like apt-get. The issue only got resolved recently, until then btrfs was effectively USELESS on any Debian based linux distributions.

          I stopped using it after I got a corrupted sector and btrfs correctly reported it. Their fsck could also report it. BUT NOTHING COULD FIX IT!!!! I ended up losing more than half of the data on the drive because it was corrupted and there exists no tools to fix errors on btrfs.
          If you're using back-level software that a distribution considers 'stable', you can't expect to have the fixes that the developers have already applied long ago. On Fedora, I run the Rawhide no-debug kernel (currently 3.12.0-0.rc5.git3.2, per: http://fedoraproject.org/wiki/RawhideKernelNodebug), and the latest btrfs-progs from Koji (http://koji.fedoraproject.org/koji/p...packageID=6398). As I said, no problems whatsoever.

          Comment


          • #15
            Originally posted by carewolf View Post
            15 months eh? You can't be using it for anything serious then. I tried it a year ago, and it was still ridiculous slow on certain operations, some of them triggered on common stuff like apt-get. The issue only got resolved recently, until then btrfs was effectively USELESS on any Debian based linux distributions.

            I stopped using it after I got a corrupted sector and btrfs correctly reported it. Their fsck could also report it. BUT NOTHING COULD FIX IT!!!! I ended up losing more than half of the data on the drive because it was corrupted and there exists no tools to fix errors on btrfs.
            Fedora and Arch its been working fine for more than 2years here. Don't complain that you had older versions of the tools, kernel, and overall filesystem at your disposal. If you're gonna be testing 'next-gen' stuff you want to be using RECENT software which probably means running a distro that tracks RECENT releases like Fedora or Arch or Gentoo or Debian Unstable. Anything else and all your complaining and problems comes down to "Hey I was using an old version of the software and found bugs!!! Didn't test to see if the new releases fixed them... YOUR GUYS' PAST SUCKS!"

            Comment


            • #16
              While I am glad that Btrfs is finally going to get some end-user testing, I will continue to be sitting pretty on ext4 for now.

              Comment


              • #17
                Originally posted by ssam View Post
                I am not using it until it has FSCK, Duke Nukem Forever is released, Steam is ported to Linux and Microsoft submits patches to the kernel.
                Looks like all of them are checked

                Comment


                • #18
                  Originally posted by ssam View Post
                  I am not using it until it has FSCK, Duke Nukem Forever is released, Steam is ported to Linux and Microsoft submits patches to the kernel.
                  Now Nvidia are contributing (Tegra K1) support to the open source Nouvoue drivers.
                  Hell must be freezing over.

                  Comment


                  • #19
                    Originally posted by mo0n_sniper View Post
                    Looks like all of them are checked
                    A working fsck thanks. One that just reports there is an error but refuses to do anything about it, is not really usefull. Losing an entire filesystem of data is not acceptable just because btrfs fucks up and refuses to try to access anything unless everything is perfect.

                    Comment


                    • #20
                      Originally posted by XorEaxEax View Post
                      BTRFS is arriving now and it has the huge advantage of being shipped and maintained directly in the Linux kernel which means it will likely quickly become the de facto default file system on Linux once it has been tested in the wild (like here with SUSE)
                      BTRFS is still breakable in a number of ways which ZFS simply shrugs off if you attempt the same things on that FS.

                      2 years later it's still not being shipped as default on any distribution.

                      So they need to act now and try to make it as painless as possible to use ZFS on Linux, which I think is what they are trying to do with ZFSOnLinux.
                      It is painless already. Seriously.

                      I don't think it will work though. The advantage of being able to be shipped in the kernel is just too big, so I believe BTRFS will become the standard on Linux and ZFS will remain largely confined to the BSD's with little to no Linux presence to speak of.
                      ZFS can never be shipped in the kernel. The CDDL is specifically written to be incompatible with GPL.

                      HOWEVER, that doesn't stop downloading zfs binaries dynamically during the setup process (in the same way that flash and microsoft codecs get pulled down dynamically) and installing them - and there are enough advantages in ZFS over BTRFS that it's worthwhile considering doing this with an installer.

                      My opinion: If it wasn't for the CDDL, ZFS would already be in widespread use on Linux and BTRFS development would probably be stagnating. The issue isn't technical, it's political.

                      BTRFS was coming "real soon now" for more than a decade, whilst it took less than 18 months for ZFS to get from alpha-quality versions on Linux to production-ready - and ZFS has the advantage of over a decade of real-world deployment in large (expensive+critical) production systems behind it.

                      ZFS works from the design starting point of "Disks are unreliable crap. Deal with it" - ie, it expects failures (and data corruption) to be regular and not only handles them but attempts to automatically repair it (the online filesystem checking is useful too). Everything else treats drive problems as a "problem" which can't be repaired in a running system and only has rudimentary handling of data corruption (detects, but does not attempt to correct)

                      It would be nice if BTRFS and ZFS devs worked together, especially now that OpenZFS development is standardising the FS across *BSD, Solaris clones and Linux but I believe I'll see ballroom dancing yaks in the lobby of Grand Central Station before that happens.

                      Comment

                      Working...
                      X