Re:Scripts for Btrfs Maintenance
by nubinetwork on Tuesday June 06, 2023 @08:54PM
(#36221322)
ZFS doesn't need it, if the file is accessed enough, it stays in cache. If the file isn't important enough, who cares that it takes a little bit longer to load into memory?
[ Parent
| on HN ]
If a ZFS dataset goes over 80% utilization, I understand it will switch from "first fit" to "best fit" which can permanently and severely impact performance.
https://serverfault.com/questions/733817/does-the-max-80-use...
Re:Scripts for Btrfs Maintenance
by LeoPanthera on Tuesday June 06, 2023 @09:55PM
(#36221834)
I actually tested this, and could not measure any performance hit at all until I hit 95% full.
It sped right back up again when I deleted some stuff.
I wouldn't worry about it.
Interesting test. Thanks for finding this out.
You can ZFS send back and forth between pools or to a new dataset to defrag/fix that, so it's not "permanent" as in can't ever be fixed. It also depends on workload, write once/read many is different from VM disk files.
Btrfs can "rebalance" in place. This has had bugs in the past, but seems safe now.
On the side of ZFS, you can take one volume of a mirrorset, move it to another system and mount it in degraded mode, and copy a bunch of new files to it. When you return the updated drive to the full set and mount it, it will resilver the older drive with the newer content automatically.
That's a killer feature. With btrfs, you have to rebalance to mirror the new files, which takes a long time as every block must be rewritten between the mirrors. ZFS knows how to move just the new files in a resilver.