• Yote.zip@pawb.social
    link
    fedilink
    English
    arrow-up
    14
    ·
    10 months ago

    Block cloning is big news. It was one of the big advantages that BTRFS had over ZFS. Now you can insta-copy files on the same filesystem, and they can share blocks with each other without being a mirrored hardlink.

    The ZSTD early abort feature is also really cool if you’re using ZSTD levels above 3. Before level 4 this system doesn’t kick in IIRC. From 4 and on, it will first try to compress the block with LZ4, and if the compression ratio with LZ4 doesn’t suck it will then attempt to compress with your chosen ZSTD level. This will give a massive performance boost to uncompressable blocks.

    • Illecors@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      10 months ago

      Now you can insta-copy files on the same filesystem, and they can share blocks with each other without being a mirrored hardlink.

      Could you elaborate on this a bit? To my understanding hard links already are the same file, it is only the inode that’s different.

      • Yote.zip@pawb.social
        link
        fedilink
        English
        arrow-up
        13
        ·
        edit-2
        10 months ago

        Reflinks with BTRFS and ZFS start off with behavior similar to hardlinks, but when you modify one of the files it doesn’t change the other one. Hard links share the same inode and edits to one file must affect the other.

        Example:

        • File A: 10GB

        • File B: Reflink’d to File A

        • 10GB total space used, 10GB shared between A and B.

        • Modify 1GB of File A

        • 1GB of new blocks created, 11GB total now used. 9 GB still shared between A and B.

        • GenderNeutralBro@lemmy.sdf.org
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          10 months ago

          The way I like to think of it is: Hard links are the same file, but with two valid paths. This is two different files that share the same data only as long as they are the same.

          But…hasn’t ZFS always had copy-on-write functionality? How is this new feature different?

          Edit: I think I found my answer here: https://www.ithands-on.com/2020/09/linux-101-zfs-filesystem-cow-system.html and I think I have fundamentally misunderstood what COW meant for years. Huh.

          • Yote.zip@pawb.social
            link
            fedilink
            English
            arrow-up
            3
            ·
            10 months ago

            CoW refers to how data is written to the disk. With CoW, data is never written back over the same block it came from, it’s always written to a new block, then the old block is unreserved after. In this way, data moves around on a CoW disk frequently. This attribute notably makes the filesystem very resilient against power loss, since data can’t be corrupted during a partial write. Only if the write is completed successfully will the old data be removed.

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    Overlay2 support is really nice. I had to use the ZFS driver for it and boy does it pollute your zfs list output.

    Also pretty excited about the user properties, it’s gonna make initramfs mounting a lot easier over the somewhat buggy parsing of the output of zfs list. Same for encrypted home directories, now I can set a custom user property on them to easily enumerate what my PAM script is supposed to mount/unmount with the user password instead of hardcoded paths.