Announcement

Collapse
No announcement yet.

Facebook To Trial Btrfs Deployments

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

  • #11
    Originally posted by benmoran View Post
    It already has many features (such as volume management) that ZFS doesn't have.
    What features in particular are you talking about? Personally I'm wating for proper RAID5/6 code, but other
    than that I can't think of anything lacking. (Besides maybe support for raw block device export, which I don't
    think is even planned).
    What do you mean by 'volume management'? ZFS has datasets which are similar to 'volumes' but far, far more flexible, as well as ZVols, which are exactly as they sound like: volumes.

    Comment


    • #12
      I haven't had any major problems with Btrfs despite running it on several production systems over the last few years... The only thing I'm still waiting to happen is bcache support, which should be landing in the kernel that is about to be released.

      Comment


      • #13
        Originally posted by kernelOfTruth View Post
        afaik got this also happening in the past - so this leaves this impression of btrfs randomly corrupting files on its own for me (of course could be wrong since it also detected a harddrive/partition that is on the verge of becoming broken - showing some more badblocks, internal errors); mentioned high memory usage (a memory leak ? on the mailing list), RAID handling when removing and re-adding a harddrive
        I also have clamav on two machines with btrfs and this has not hapenned yet. It only OOPS-ed during boot on a 32bit UP machine (probably a race).

        Originally posted by kernelOfTruth View Post
        and of course this issue with ENOSPEC/free space fragmentation and/or non-reclaim of free space
        Had that too. If you retry again, the copy might work. That is indeed odd and weird.

        Originally posted by kernelOfTruth View Post
        this might be a side-effect of Btrfs' COW nature but at this late (?) point of development it slowly should be tackled and must not need an manual (especially advanced user) intervention to continue to be usable

        if development continues like that it will again take years until the round edges are smoothened out

        it has come a long way and improved a lot but there's still the feeling that fundamental mechanisms and parts are missing underneath
        Altough it's nice to read about the technical details underlying these problems, it's indeed not going to cut it for production use.

        Luckily I also migrated all of my machines to lvm, so moving back to ext4 or tux3 should not be much of a problem.

        Comment


        • #14
          richACLs?

          I am using btrfs on my laptop. My Samba-Server is using reiserfs on a raid disk.

          The only thing I miss at btrfs is richacls-support, but i think that feature will never come to btrfs.

          Comment


          • #15
            Originally posted by kernelOfTruth View Post
            local copies ?

            copies=3

            lz4 compression ?

            more advanced checksums than crc32c (e.g. sha256) ?

            easy to use / user-friendly expert tools ?

            trivial errors or "features" that are not showing during routine checks ? (e.g. the checksum missing for space_cache)
            an inode_cache that doesn't take minutes to regenerate after having shut down the "links" browser and in the process slowing down the system to a crawl ?

            actual NO slowing down during heavy i/o writes of the *entire* system compared to ext4 ? (on dm-crypt)

            stability ? (already got corrupted files on /home; after a few crashes (hardlocks) the /home directory got that much messed up that the kernel would panic or couldn't access /home anymore)

            these are all working features that are currently available on ZFSonLinux

            this is not to badmouth Btrfs - rather a rant since I'm personally interested in a 2nd drop-in filesystem that could also be used on /home instead of ZFS (which doesn't support realtime kernels yet and suspend-to-disk, probably suspend-to-ram neither) - especially on the laptop to fully use energy-saving and time-saving features while maintaining maximum data integrity & -safety
            Some valid points, and some opinion in there.

            If I remember correctly, the "copies=3" (or more) work is something that should show up after raid 5/6 scrubbing support is ready.

            The lz4 compression seems to be really wanted by some, but I get the impression that not many people are interested enough to work on it. I don't use this kind of file system for space savings personally, so I am one of those that is happy with lzo.

            I can't comment on the dm-crypt stuff, since I don't use it. Valid complaint though, as it seems like built-in encryption is not being considered.

            Af far as stability and corruption, I've only had issues once with the known balance bug on a recent kernel. I've personally used btrfs on many machines at home and in the lab, some of which are hard reset many many times. I've not had any corruption in a dozen file systems. I know people have issues, but with recent code I consider it quite stable.

            Some valid points, but I don't think it's fair to say it will take years to catch up to ZFS' features - because some are not planned to be included at all.

            Comment


            • #16
              Originally posted by JX8p View Post
              What do you mean by 'volume management'? ZFS has datasets which are similar to 'volumes' but far, far more flexible, as well as ZVols, which are exactly as they sound like: volumes.
              Sorry, I meant to say "flexible volume management". Obviously ZFS has some form of "volume" management. The terminology is different, but ZFS does have the ability to expose raw block-like volumes which btrfs lacks. I was referring to management of physical disks and subvolumes. With ZFS, once you create an array of disks, you're very limited in what you can do. You cannot simply add an additional disk and expand. This is not really a weakness, as ZFS was designed with servers in mind. Generally if you created a 12-disk array on a 2U server, you're always going to have 12 disks. It's lacking when used in desktops and home storage servers where people might need more flexibility to grow later. Btrfs is able to start with a single disk, add some disks later, and rebalance to a different raid level online. You can even remove a few disks, replace them with bigger mismatched ones, and rebalance online. You can do pretty much whatever you want in this regard, making it much more flexible for home users.

              Comment


              • #17
                There are things people always don't know or forgot to mention.

                I believe Suse disables the multi-device support in btrfs in their kernels.

                They say, the general filesystem is stable, it's the multi-device support that they don't support yet.

                Comment


                • #18
                  Originally posted by kernelOfTruth View Post
                  more advanced checksums than crc32c (e.g. sha256) ?
                  Is that really needed. With a 32bit checksum, there is only a 1 in a billion chance that a corrupt block will go undetected. That sounds good enough for me. More advanced checksums only required if you are trying to defend against deliberate tampering, but if someone has access to tamper with the data on your disk, then they can also update the checksum. If the 1 in a billion is not enough for you then crc64 should be enough and will be much faster than sha.

                  Comment


                  • #19
                    Originally posted by ssam View Post
                    Is that really needed. With a 32bit checksum, there is only a 1 in a billion chance that a corrupt block will go undetected. That sounds good enough for me. More advanced checksums only required if you are trying to defend against deliberate tampering, but if someone has access to tamper with the data on your disk, then they can also update the checksum. If the 1 in a billion is not enough for you then crc64 should be enough and will be much faster than sha.
                    Well, just having crc32 might not be enough, but crc32c is and that's what btrfs uses.

                    And certain CPUs have SSE4.2 support, which has crc32c support as well.

                    Comment

                    Working...
                    X