OpenZFS Office Hours with Matt Ahrens
Why Hacker News recommends it
Cited as the authoritative explanation of why block pointer rewrite is so hard to implement in ZFS.
What it is
An OpenZFS office hours session with ZFS co-creator Matt Ahrens answering questions on topics such as hole birth time, send/receive buffers, device removal, block pointer rewrite and performance with many snapshots.
Recommended by 0 HN commenters across 0 different months, 2014 to 2023.
What Hacker News said
Cites wtallis · 2014-11 · on “Ask HN: Can we talk about FreeBSD vs. Linux?”
[this video] The above video is an explanation of a bunch of the barriers to implementing block pointer rewrites. The conclusion is that it would make the code a lot more complicated and break a lot of the layering, and probably make addition of other new features a lot harder. Even a standalone offline rewriting tool wouldn't necessarily be accepted into the OpenZFS codebase because of the maintenance burden. Their advice is that if you think you need that feature to solve a particular problem, you should be looking for a workaround to solve that problem without requiring the huge block pointer rewrite project (which nobody's working on), even if the workarounds have a significant and permanent
Cites raattgift · 2017-07 · on “ZFS Is the Best Filesystem For Now”
> Illumos has a way to expand pools ... ZFS creates a vdev inside the new larger vdev Huh? > IDK if that's in OpenZFS yet. The openzfs tree (on github) is virtually identical to illumos-gate (on github). > physical block addresses should never have been part of the ZFS Merkle hash tree, thus allowing physical addresses to change without having to rewrite every block from the root down. mahrens deals with this (and block pointer rewriting) here: [this video] Even with SSDs IOPS are precious. On rotating media, burning track-to-track seeks in reading and updating a large hash table is a bad plan (cf. the deduplication table).
Cites ploek · 2023-03 · on “Benchmarking Cheap SSDs for Fun, No Profit (Be Warned)”
No, there is no defragmentation for ZFS, unfortunately. A way to get around that is to send the pool's content to another (fresh) ZFS pool, where it would be written sequentially. But for that you would need a set of drives of same (or larger) capacity. There are ideas on how one would do an actual defrag. They are generally based on a concept called block pointer rewrite, which Matt Ahrens once said could be the 'last feature ever implemented in ZFS', as it would make everything so much more complicated, that it would be hard to add new features afterwards [1]. [1] [this video] (Link to the beginning of the explanation, the 'last feature ever implemented' quote is at at around 50:25)
Cites drbawb · 2023-07 · on “List of Unix binaries that can be used to bypass local security restrictions”
On my system the root account is primarily for upgrades, but also storage administration! ZFS snapshots protects me against silly mistakes like strange permutations of `rm -rf ~/` in day to day operations. Not having root all the time protects me against `zfs destroy -r nagato/data/home/drbawb` which will nuke my home folder, 144 frequent snapshots (15 minute intervals per 36 hours), 14 daily snapshots, 4 weekly snapshots, and 3 monthly snapshots. That would suck. A lot. (I have a file called "RIP", where a drive image used to be mounted, because I got a little too over-zealous with the recursive option on some ZFS commands on a file that had `copies=1`. _RAID is not a backup, snapshots are