From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Xin Yin <yinxin.x@bytedance.com>
Cc: harshadshirwadkar@gmail.com, tytso@mit.edu,
adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] ext4: use ext4_ext_remove_space() for fast commit replay delete range
Date: Wed, 2 Feb 2022 02:03:59 +0530 [thread overview]
Message-ID: <20220201203359.owrnrfqydjloy7oq@riteshh-domain> (raw)
In-Reply-To: <20211223032337.5198-2-yinxin.x@bytedance.com>
Hello Xin,
Sorry about revisiting this thread so late :(
Recently when I was working on one of the fast_commit issue, I got interested
in looking into some of those recent fast_commit fixes.
Hence some of these queries.
On 21/12/23 11:23AM, Xin Yin wrote:
> For now ,we use ext4_punch_hole() during fast commit replay delete range
> procedure. But it will be affected by inode->i_size, which may not
> correct during fast commit replay procedure. The following test will
> failed.
>
> -create & write foo (len 1000K)
> -falloc FALLOC_FL_ZERO_RANGE foo (range 400K - 600K)
> -create & fsync bar
^^^^ do you mean "fsync foo" or is this actually a new file create and fsync
bar?
> -falloc FALLOC_FL_PUNCH_HOLE foo (range 300K-500K)
> -fsync foo
> -crash before a full commit
>
> After the fast_commit reply procedure, the range 400K-500K will not be
> removed. Because in this case, when calling ext4_punch_hole() the
> inode->i_size is 0, and it just retruns with doing nothing.
I tried looking into this, but I am not able to put my head around that when
will the inode->i_size will be 0?
So, what I think should happen is when you are doing falocate/fsync foo in your
above list of operations then, anyways the inode i_disksize will be updated
using ext4_mark_inode_dirty() and during replay phase inode->i_size will hold
the right value no?
Could you please help understand when, where and how will inode->i_size will be
0?
Also - it would be helpful if you have some easy reproducer of this issue you
mentioned.
-ritesh
>
> Change to use ext4_ext_remove_space() instead of ext4_punch_hole()
> to remove blocks of inode directly.
>
> Signed-off-by: Xin Yin <yinxin.x@bytedance.com>
> ---
> fs/ext4/fast_commit.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index aa05b23f9c14..3deb97b22ca4 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -1708,11 +1708,14 @@ ext4_fc_replay_del_range(struct super_block *sb, struct ext4_fc_tl *tl,
> }
> }
>
> - ret = ext4_punch_hole(inode,
> - le32_to_cpu(lrange.fc_lblk) << sb->s_blocksize_bits,
> - le32_to_cpu(lrange.fc_len) << sb->s_blocksize_bits);
> - if (ret)
> - jbd_debug(1, "ext4_punch_hole returned %d", ret);
> + down_write(&EXT4_I(inode)->i_data_sem);
> + ret = ext4_ext_remove_space(inode, lrange.fc_lblk,
> + lrange.fc_lblk + lrange.fc_len - 1);
> + up_write(&EXT4_I(inode)->i_data_sem);
> + if (ret) {
> + iput(inode);
> + return 0;
> + }
> ext4_ext_replay_shrink_inode(inode,
> i_size_read(inode) >> sb->s_blocksize_bits);
> ext4_mark_inode_dirty(NULL, inode);
> --
> 2.20.1
>
next prev parent reply other threads:[~2022-02-01 20:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 3:23 [PATCH 0/2] ext4: fast commit crash consistency issues Xin Yin
2021-12-23 3:23 ` [PATCH 1/2] ext4: use ext4_ext_remove_space() for fast commit replay delete range Xin Yin
2021-12-23 20:11 ` harshad shirwadkar
2022-02-01 20:33 ` Ritesh Harjani [this message]
2022-02-02 13:40 ` [External] " Xin Yin
2022-02-03 21:14 ` Ritesh Harjani
2022-02-04 11:36 ` Jan Kara
2022-02-05 10:40 ` Ritesh Harjani
2021-12-23 3:23 ` [PATCH 2/2] ext4: fast commit may miss tracking unwritten range during ftruncate Xin Yin
2021-12-23 20:11 ` harshad shirwadkar
2021-12-23 20:13 ` [PATCH 0/2] ext4: fast commit crash consistency issues harshad shirwadkar
2021-12-24 0:27 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220201203359.owrnrfqydjloy7oq@riteshh-domain \
--to=riteshh@linux.ibm.com \
--cc=adilger.kernel@dilger.ca \
--cc=harshadshirwadkar@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yinxin.x@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox