Announcement

Collapse
No announcement yet.

SUSE Remains Committed To The Btrfs File-System

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

  • #51
    Originally posted by starshipeleven View Post
    His is a simplification, but it's roughly like that.

    Of course there are various levels of safe, but also MS has their own next-gen fs with checksumming and LVM and stuff and it runs worse than plain NTFS (or FAT32 for that matter).
    yeah I totally forgot about ReFS, have to ask around if someone in the windows side storage service how is working now, last time in WS 2016 was a mess from what I heard in some circles

    Comment


    • #52
      Originally posted by sdack View Post
      To which I say...

      Just where is the logic?! If not having a problem with something is your sole reason for using btrfs then you're having a problem.
      I should have elaborated. I guess a straightforward read of my original comment would imply I was making an argument that I could have made with FAT32 in place of btrfs. To be clear, I was asking what specific features ZFS has that btrfs does not.

      Both have:
      1. File and directory checksum'ing with automatic healing.
      2. Transparent encryption.
      3. Transparent compression.
      4. Growing and shrinking volumes live.
      5. Copy-on-write.
      6. Snapshots.

      Advantages of btrfs:
      1. Subvolumes, including subvolume snapshots.
      2. Anecdotally, ZFS is relatively RAM and CPU hungry.

      Advantages of ZFS:
      1. Mature support for RAID versions other than 0, 1, 10. (Support for other forms of RAID is experimental in btrfs.)
      2. Maturity in general.

      So I think btrfs has plenty to offer me as a home user. I have it on six drives, and I have subvolumes and snapshots and so forth. I also have backup automation in place: rsync between three computers through anacron and SpiderOak for offsite backups.

      (Edit) And to be clear, I think it's a hundred time more likely that btrfs code in the Linux kernel keeps getting tweaked until it's as solid as ZFS than for ZFS ever to get relicensed in a way friendly to Linux.

      Comment


      • #53
        Originally posted by Michael_S View Post
        2. Transparent encryption.
        This is a nope for btrfs (no patch for it was ever merged), and for open ZFS (on linux) it's a very new feature that happened by cloning the whole crypto subsystem from Illumos kernel https://www.phoronix.com/forums/foru...yption-support

        Comment


        • #54
          Originally posted by roelandjansen View Post

          did you read Matthias' story? I know him personally and all you wrote is really not in sync with his or SUSE's thought.

          ZFS under linux does exist but we all know that licensing is an issue for some products / environments.
          Just a matter of perspective coloring, I'd say it's inline and complementing with his position. They're invested with it and are doing what they consider the best next move. In my eyes I see them in a awkward position and of being a lone knight, which doesn't have good odds of sustaining the test of time. Btrfs will in all likely prove to be a liability more than an asset.

          The licensing issue is nowhere near as complicated as you make it out to be, to support or use as an enterprise customer. The government themselves use it often, along with national labs and universities. Llnl, eg experts in data and needs, built zfsonlinux specifically because it was much lower hanging fruit and out of the clusterfk oracle and distros created.. If you're not on ext4 or xfs, you're on zfs.
          Last edited by nevion; 26 August 2017, 02:34 AM.

          Comment


          • #55
            Originally posted by Delgarde View Post

            Because "proper abstraction" isn't always the best answer. Separating everything out into cleanly defined layers makes for better code, but it has a cost - everything is responsible for just its own area of responsibility, and nobody has a big-picture view. If you merge some of the layers - erasing the division between volume management and filesystem - you get more complexity, but you also get the ability to optimise in ways that can't occur when responsibilities are divided.
            well, "layer" in a monolithic kernel only meaning a near zero cost jump or two, ... nothing like expensive context switches or such, ... I rather have a stable storage system without duplicated functionality all over the kernel, ...

            Comment


            • #56
              Originally posted by starshipeleven View Post
              This is a nope for btrfs (no patch for it was ever merged), and for open ZFS (on linux) it's a very new feature that happened by cloning the whole crypto subsystem from Illumos kernel https://www.phoronix.com/forums/foru...yption-support
              Thanks for the correction. Transparent encryption is listed for btrfs on Wikipedia, but I haven't seen you post anything wildly inaccurate before so I'll take you at your word.

              Comment


              • #57
                Originally posted by Michael_S View Post
                Thanks for the correction. Transparent encryption is listed for btrfs on Wikipedia, but I haven't seen you post anything wildly inaccurate before so I'll take you at your word.
                Thanks for trusting me, will still post some proof, just in case.
                btrfs wiki https://btrfs.wiki.kernel.org/index...._encryption.3F
                and a mail in the mailing list from a maintainer answering a Google employee asking for that feature some months ago https://marc.info/?l=linux-btrfs&m=149727131222766&w=2

                And by looking at wikipedia it shows "planned" https://en.wikipedia.org/wiki/Btrfs so you probably misread.

                Comment


                • #58
                  Originally posted by rene View Post
                  well, "layer" in a monolithic kernel only meaning a near zero cost jump or two, ... nothing like expensive context switches or such, ... I rather have a stable storage system without duplicated functionality all over the kernel, ...
                  Well, we all would like to, but keeping stuff generic and layered means that now you don't just have to plan for your own filesystem's use, but for everyone else's. This will eventually force tradeoffs.
                  So going on their own is actually easier to deal with, and considering btrfs/ZFS do have some unusual requirements, speeds up development.
                  Really we should not cargo-cult general development guidelines, sometimes it makes sense to go on your own.

                  Also f2fs has his own RAID-like functionality now, for the same reasons.
                  Last edited by starshipeleven; 26 August 2017, 01:09 PM.

                  Comment


                  • #59
                    I experimented with using OpenSUSE'S btrfs root file-system for my home desktop late last year.

                    Because I wanted to replicate my offline backups and restore procedures, I had to spend a considerable amount of time digging out undocumented conventions concerning how the root is structured, how the sub-volumes are layed out, and how you might go about creating a root manually from scratch. I wrote it up here:

                    https://forums.opensuse.org/showthre...lume-structure

                    If you already familiar with all the info I collected in my notes, I suspect you are in a good position to use btrfs. If you don't, you could be headed for some surprises.

                    In the end I found the added complexity too high a price to pay for any of the features on offer. I decided to wait a year or two and see if the btrfs documentation and tooling matures.

                    Comment


                    • #60
                      Originally posted by cjcox View Post

                      You need to hang around here for awhile. There are few sacred cows that you aren't allowed to touch.
                      Just so I'm clear, when I spoke of troll baiting, I was referring to "In before (people with different opinions) get here" part. It's never good.

                      1) It makes me not want to listen to what you have to say.

                      2) It causes any of (those people) to start taking the bait, even if you meant it in jest.

                      3) It tells everyone reading exactly how you feel about an entire group of people, or at least, makes it seem like you feel a certain way. Doing so, you essentially said that one group of people will be the irrational ones.

                      Comment

                      Working...
                      X