On Jul 24, 2019, at 12:14 PM, harshad shirwadkar <harshadshirwadkar@xxxxxxxxx> wrote: > > On Wed, Jul 24, 2019 at 9:56 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: >> >> (I guess you could have a fastcommit_version field that increments every >> time you add a new fastcommit journal item to constrain the combinatoric >> explosion...) > > I agree, I was going to suggest the same. We would probably need to > add this field in all individual fast commit blocks, since we don't > have a fast commit superblock equivalent .. and changing jbd2 > superblock is probably too much to ask for I guess. As a general design rule, whenever you see/think "version number", you should instead use "feature flags" as is done in the ext2/3/4 superblock. This doesn't take any more space, and is much more flexible. This is a _much_ more flexible paradigm for compatibility, and doesn't require the "version X must support every version <= X" behaviour that a version number does. With feature flags you can support feature bit a+b+c, and if feature B is no longer useful it can be deprecated without affecting the use of feature A or C. It also makes it clear that bits a+b+c are using features A+B+C, while storing "version 7" isn't clear which feature is in use/needed. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
