*cough* fsck tool *cough* /Tomas -- Written on a tiny keyboard
On 8 July 2016 2:31:18 am "Rich" <rincebr...@gmail.com> wrote: > 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
