Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 9 Mar 2022 10:52:48 +0100
From:   Jan Kara <jack@suse.cz>
To:     harshad shirwadkar <harshadshirwadkar@gmail.com>
Cc:     Jan Kara <jack@suse.cz>,
        Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Ritesh Harjani <riteshh@linux.ibm.com>,
        "Theodore Y. Ts'o" <tytso@mit.edu>
Subject: Re: [PATCH 3/5] ext4: for committing inode, make ext4_fc_track_inode
 wait
Message-ID: <20220309095248.v7kj3ss2kn6kva54@quack3.lan>
References: <20220308105112.404498-1-harshads@google.com>
 <20220308105112.404498-4-harshads@google.com>
 <20220308123020.u4357jwbtoqhy5xd@quack3.lan>
 <CAD+ocbzwGW91MdnwBS2hZ_W+kum-cSpUfAWYJ0jU0xjnt3Y_SQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAD+ocbzwGW91MdnwBS2hZ_W+kum-cSpUfAWYJ0jU0xjnt3Y_SQ@mail.gmail.com>
Precedence: bulk

On Tue 08-03-22 05:06:51, harshad shirwadkar wrote:
> On Tue, 8 Mar 2022 at 04:30, Jan Kara <jack@suse.cz> wrote:
> > > diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
> > > index 3477a16d08ae..7fa301b0a35a 100644
> > > --- a/fs/ext4/ext4_jbd2.c
> > > +++ b/fs/ext4/ext4_jbd2.c
> > > @@ -106,6 +106,18 @@ handle_t *__ext4_journal_start_sb(struct super_block *sb, unsigned int line,
> > >                                  GFP_NOFS, type, line);
> > >  }
> > >
> > > +handle_t *__ext4_journal_start(struct inode *inode, unsigned int line,
> > > +                               int type, int blocks, int rsv_blocks,
> > > +                               int revoke_creds)
> > > +{
> > > +     handle_t *handle = __ext4_journal_start_sb(inode->i_sb, line,
> > > +                                                type, blocks, rsv_blocks,
> > > +                                                revoke_creds);
> > > +     if (ext4_handle_valid(handle) && !IS_ERR(handle))
> > > +             ext4_fc_track_inode(handle, inode);
> >
> > Why do you need to call ext4_fc_track_inode() here? Calls in
> > ext4_map_blocks() and ext4_mark_iloc_dirty() should be enough, shouldn't
> > they?
> This is just a precautionary call. ext4_fc_track_inode is an
> idempotent function, so it doesn't matter if it gets called multiple
> times. This check just covers cases (such as the ones in inline.c)
> where ext4_reserve_inode_write() doesn't get called. I saw a few
> failures in the log group when I remove this call. The right way to
> fix this though is to ensure that ext4_reserve_inode_write() gets
> called before every inode update.

Oh, you mean like when updating inline data? I'm not sure
ext4_reserve_inode_write() is usable for all the places in inline.c but
yes, you probably need some sprinkling of ext4_fc_track_inode() there. That
would be definitely better than hacking it around in
__ext4_journal_start().

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