linux-ext4 - Re: [PATCH v10 2/9] ext4: add fast_commit feature and handling for extended mount options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201022130908.GD24163@quack2.suse.cz>
Date:   Thu, 22 Oct 2020 15:09:08 +0200
From:   Jan Kara <jack@...e.cz>
To:     harshad shirwadkar <harshadshirwadkar@...il.com>
Cc:     Jan Kara <jack@...e.cz>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        "Theodore Y. Ts'o" <tytso@....edu>
Subject: Re: [PATCH v10 2/9] ext4: add fast_commit feature and handling for
 extended mount options

On Wed 21-10-20 10:31:48, harshad shirwadkar wrote:
> On Wed, Oct 21, 2020 at 9:18 AM Jan Kara <jack@...e.cz> wrote:
> >
> > On Thu 15-10-20 13:37:54, Harshad Shirwadkar wrote:
> > > We are running out of mount option bits. Add handling for using
> > > s_mount_opt2. Add ext4 and jbd2 fast commit feature flag and also add
> > > ability to turn off the fast commit feature in Ext4.
> > >
> > > Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@...il.com>
> > > ---
> > >  fs/ext4/ext4.h       |  4 ++++
> > >  fs/ext4/super.c      | 27 ++++++++++++++++++++++-----
> > >  include/linux/jbd2.h |  5 ++++-
> > >  3 files changed, 30 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > > index 1879531a119f..02d7dc378505 100644
> > > --- a/fs/ext4/ext4.h
> > > +++ b/fs/ext4/ext4.h
> > > @@ -1213,6 +1213,8 @@ struct ext4_inode_info {
> > >  #define EXT4_MOUNT2_EXPLICIT_JOURNAL_CHECKSUM        0x00000008 /* User explicitly
> > >                                               specified journal checksum */
> > >
> > > +#define EXT4_MOUNT2_JOURNAL_FAST_COMMIT      0x00000010 /* Journal fast commit */
> > > +
> > >  #define clear_opt(sb, opt)           EXT4_SB(sb)->s_mount_opt &= \
> > >                                               ~EXT4_MOUNT_##opt
> > >  #define set_opt(sb, opt)             EXT4_SB(sb)->s_mount_opt |= \
> > > @@ -1813,6 +1815,7 @@ static inline bool ext4_verity_in_progress(struct inode *inode)
> > >  #define EXT4_FEATURE_COMPAT_RESIZE_INODE     0x0010
> > >  #define EXT4_FEATURE_COMPAT_DIR_INDEX                0x0020
> > >  #define EXT4_FEATURE_COMPAT_SPARSE_SUPER2    0x0200
> > > +#define EXT4_FEATURE_COMPAT_FAST_COMMIT              0x0400
> > >  #define EXT4_FEATURE_COMPAT_STABLE_INODES    0x0800
> >
> > Is fast commit really a compat feature? IMO if there are fast commits
> > stored in the journal, the filesystem is actually incompatible with the
> > old kernels because data we guranteed to be permanenly stored may be
> > invisible for the old kernel (since it won't replay fastcommit
> > transactions).
> >
> > ...
> >
> > Oh, now I see that the journal FAST_COMMIT is actually incompat. So what's
> > the point of compat ext4 feature with incompat JBD2 feature?
> So having fast commits enabled on an ext4 file system doesn't
> immediately make it incompatible with the older kernels. FS becomes
> incompatible only if there are fast commits blocks that are stored in
> the journal. So, one of the tricks that this patchset does is on a
> clean unmount, since it's guaranteed that there are no fast commit
> blocks in journal, we clear out the JBD2 incompat flag and preserve
> the compat flag in ext4. So, we can think of ext4 compat flag as "FS
> will try fast commits when possible" while jbd2 incompat flag as
> "There are fast commits blocks present in the journal". Does that make
> sense?

Yes, understood. That's clever. Thanks for explanation! But please add the
above justification to the description of EXT4_FEATURE_COMPAT_FAST_COMMIT
feature or somewhere around that.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR