Announcement

Collapse
No announcement yet.

Btrfs Gets Fixes For Linux 4.9, Linux 4.10 To Be More Exciting

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

  • Btrfs Gets Fixes For Linux 4.9, Linux 4.10 To Be More Exciting

    Phoronix: Btrfs Gets Fixes For Linux 4.9, Linux 4.10 To Be More Exciting

    Chris Mason sent in the Btrfs file-system changes this morning for the Linux 4.9 kernel merge window...

    http://www.phoronix.com/scan.php?pag...nges-Linux-4.9

  • #2
    suggested: rm -rf btrfs/

    Comment


    • #3
      Btrfs will take another 10 years. And I hate to see the typical C bugs in the change logs...

      Comment


      • #4
        Although I've been running btrfs for a number of years now, and haven't had any issues for, again, a number of years, I'm really beginning to lose interest in it and am looking forward, instead, to upcoming xfs changes (snapshots! data scrubbing! COW!), bcachefs (though I wish Ken was working somewhere that would provide him with more support because I think avoiding the vfs layer is the right direction), and ceph's bluestore (another storage mechanism that ignores the vfs---in this case it's not really intended for a single machine, and it's more of an object store but you can still you the cephfs protocol to address it like a filesystem but you are able to get guarantees that posix filesystems can't provide).
        Of course, I would still like to see the btrfs folks succeed because their work definitely has its place, and their needs have led to improvements to the vfs layer.

        Steffo Possibly. These things never seem to be quite done. I don't think they've had data eating bugs for a while (as long as you stayed on the marked path). The C bugs are, unfortunately, something that's going to have to be lived with until they move to another language or start using the tooling ,like some have adopted Coccinelle as part of their CI... FRANKLY, just moving to a CI workflow, as standard practice, would be a great start.
        Last edited by liam; 11 October 2016, 01:46 PM.

        Comment


        • #5
          Is there really any practical advantage of using BTRFS over ZFS at this time?

          Comment


          • #6
            Originally posted by liam View Post
            Although I've been running btrfs for a number of years now, and haven't had any issues for, again, a number of years, I'm really beginning to lose interest in it and am looking forward, instead, to upcoming xfs changes (snapshots! data scrubbing! COW!), bcachefs (though I wish Ken was working somewhere that would provide him with more support because I think avoiding the vfs layer is the right direction), and ceph's bluestore (another storage mechanism that ignores the vfs---in this case it's not really intended for a single machine, and it's more of an object store but you can still you the cephfs protocol to address it like a filesystem but you are able to get guarantees that posix filesystems can't provide).
            I'm not; Btrfs is now getting real solid, with autobalancing and so on, and that's really all I'd ever want from it now. No new and exciting things are necessary any more.

            Comment


            • #7
              Originally posted by ElectricPrism View Post
              Is there really any practical advantage of using BTRFS over ZFS at this time?
              Besides being part of the mainline kernel?

              Actually a tangible benefit is that you can move things around, i.e. upgrade/migrate without being forced to buy more disks. Updating ZFS almost always requires buying a slew of new disks, which isn't usually a problem for a datacenter.

              Comment


              • #8
                Originally posted by GreatEmerald View Post

                I'm not; Btrfs is now getting real solid, with autobalancing and so on, and that's really all I'd ever want from it now. No new and exciting things are necessary any more.
                I'd actually like to use RAID5/6. I have quite a bit of data, I do have off-site backups, but those are a pain to use, and I don't havethe capacity to use RAID1...

                Comment


                • #9
                  Native per-volume encryption is pretty high on the list for me.

                  Comment


                  • #10
                    Originally posted by liam View Post
                    Steffo Possibly. These things never seem to be quite done. I don't think they've had data eating bugs for a while (as long as you stayed on the marked path). The C bugs are, unfortunately, something that's going to have to be lived with until they move to another language or start using the tooling ,like some have adopted Coccinelle as part of their CI... FRANKLY, just moving to a CI workflow, as standard practice, would be a great start.
                    The greatest value from continuous integration is if you have a pretty heavy set of automated tests.

                    Comment

                    Working...
                    X