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.
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.
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?
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.
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.
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.
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.