[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <FA794079-BB03-483C-A89C-3A6F72B06E98@dilger.ca>
Date: Thu, 25 Jul 2019 14:03:24 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: harshad shirwadkar <harshadshirwadkar@...il.com>
Cc: "Darrick J. Wong" <darrick.wong@...cle.com>,
"Theodore Y. Ts'o" <tytso@....edu>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 01/11] ext4: add handling for extended mount options
On Jul 24, 2019, at 12:14 PM, harshad shirwadkar <harshadshirwadkar@...il.com> wrote:
>
> On Wed, Jul 24, 2019 at 9:56 AM Darrick J. Wong <darrick.wong@...cle.com> 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
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists