Hi all, So, ZFS on Linux just noticed it was getting bitten by what ultimately turned out to be Illumos #6513, partially filled holes losing birth time.
Implementing that fix removes this problem for new data, but on all platforms, this doesn't help data already written on existing pools, getting munged silently in incremental sends forever. pcd pointed out that a relatively trivial workaround would be possible by simply ignoring the hole_birth metadata with something like a global tunable, but that seems too heavy-handed to me - either you're disabling the feature everywhere because you don't know when you can start trusting the birth times, or you're risking silent mangling of affected files forever. I'd like to suggest using a read-compatible feature, call it something like hole_birth_fix, in conjunction with the enabled_txg feature, to permit a reasonable default of ignoring hole_birth information before the hole_birth_fix feature was enabled, but still permitting use of it afterward. This has the unfortunate behavior of breaking write support if you enable hole_birth_fix and then try to go back to a prior codebase, but I can't think of a reasonable way to avoid this. I filed illumos #7175 to track this proposal - I'll happily write the code to implement this shortly. (Apologies if I've over-CCed or missed someone I should be asking for comment, I've not done this workflow before.) - Rich ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
