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  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]
Date:   Mon, 26 Oct 2020 09:40:15 -0700
From:   harshad shirwadkar <harshadshirwadkar@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     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

Will do, thanks!

On Thu, Oct 22, 2020 at 6:09 AM Jan Kara <jack@...e.cz> wrote:
>
> 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

Powered by blists - more mailing lists