On Thu, Sep 1, 2016 at 6:07 AM, Rich <[email protected]> wrote: >> A short question about the design: can you please elaborate just how is it >> backwards-compatible? ;-) For example, if I boot into an older BE or LiveCD >> and write something to the pool, there will be TXGs that are newer than the >> mintxg but written with potentially buggy software. Or are there failsafes >> like storing a chain of (mintxg;maxtxg) pairs written only by the bugless >> version (and a new chain link starts if the largest stored maxtxg is not the >> current txg at pool import)? Or would this pool just not import (r/w) into >> older kernels anymore, due to the new feature? >> >> Thanks, >> Jim > > > AIUI the mechanism being proposed by Matt is that, on import with a "fixed" > system, if the pool has a maxtxg above the maxtxg in the bugfix data > structure, it updates mintxg to maxtxg, and thereby treats every block > before the current import as untrusted. > > So changing between an unfixed and fixed system would result in you treating > all the txgs before the most recent fixed system import as potentially > buggy, rather than maintaining a range list.
That's correct. We rely on unfixed systems not updating the maxtxg, detect that when the pool is opened on a fixed system, and then reset the on-disk state to reflect the fact that nothing before the current time can be trusted (mintxg = maxtxg = current txg). --matt ------------------------------------------- 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
