Announcement

Collapse
No announcement yet.

Facebook To Trial Btrfs Deployments

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

  • #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