From: Jan Kara <jack@suse.cz>
To: Zhang Yi <yi.zhang@huaweicloud.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org,
willy@infradead.org, yi.zhang@huawei.com,
chengzhihao1@huawei.com, yukuai3@huawei.com,
wangkefeng.wang@huawei.com
Subject: Re: [RFC PATCH v2 03/25] ext4: correct the hole length returned by ext4_map_blocks()
Date: Wed, 3 Jan 2024 12:02:55 +0100 [thread overview]
Message-ID: <20240103110255.7uebqb2iy4jcy6sh@quack3> (raw)
In-Reply-To: <20240102123918.799062-4-yi.zhang@huaweicloud.com>
On Tue 02-01-24 20:38:56, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
>
> In ext4_map_blocks(), if we can't find a range of mapping in the
> extents cache, we are calling ext4_ext_map_blocks() to search the real
> path and ext4_ext_determine_hole() to determine the hole range. But if
> the querying range was partially or completely overlaped by a delalloc
> extent, we can't find it in the real extent path, so the returned hole
> length could be incorrect.
>
> Fortunately, ext4_ext_put_gap_in_cache() have already handle delalloc
> extent, but it searches start from the expanded hole_start, doesn't
> start from the querying range, so the delalloc extent found could not be
> the one that overlaped the querying range, plus, it also didn't adjust
> the hole length. Let's just remove ext4_ext_put_gap_in_cache(), handle
> delalloc and insert adjusted hole extent in ext4_ext_determine_hole().
>
> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
> Suggested-by: Jan Kara <jack@suse.cz>
Some small comments below.
> @@ -4062,6 +4038,66 @@ static int get_implied_cluster_alloc(struct super_block *sb,
> return 0;
> }
>
> +/*
> + * Determine hole length around the given logical block, first try to
> + * locate and expand the hole from the given @path, and then adjust it
> + * if it's partially or completely converted to delayed extents.
> + */
> +static void ext4_ext_determine_hole(struct inode *inode,
> + struct ext4_ext_path *path,
> + struct ext4_map_blocks *map)
> +{
I'd prefer to keep setting of 'map' inside ext4_ext_map_blocks() to make it
more obvious there and just pass map->m_lblk into
ext4_ext_determine_hole(). ext4_ext_determine_hole() will just return the
length of the extent from lblk that was mapped (i.e. 'len').
Also I'd probably call this function like ext4_ext_determine_insert_hole()
to make it more obvious the function modifies the status tree.
Otherwise the patch looks good to me.
Honza
> + ext4_lblk_t hole_start, len;
> + struct extent_status es;
> +
> + hole_start = map->m_lblk;
> + len = ext4_ext_find_hole(inode, path, &hole_start);
> +again:
> + ext4_es_find_extent_range(inode, &ext4_es_is_delayed, hole_start,
> + hole_start + len - 1, &es);
> + if (!es.es_len)
> + goto insert_hole;
> +
> + /*
> + * Found a delayed range in the hole, handle it if the delayed
> + * range is before, behind and straddle the queried range.
> + */
> + if (map->m_lblk >= es.es_lblk + es.es_len) {
> + /*
> + * Before the queried range, find again from the queried
> + * start block.
> + */
> + len -= map->m_lblk - hole_start;
> + hole_start = map->m_lblk;
> + goto again;
> + } else if (in_range(map->m_lblk, es.es_lblk, es.es_len)) {
> + /*
> + * Straddle the beginning of the queried range, it's no
> + * longer a hole, adjust the length to the delayed extent's
> + * after map->m_lblk.
> + */
> + len = es.es_lblk + es.es_len - map->m_lblk;
> + goto out;
> + } else {
> + /*
> + * Partially or completely behind the queried range, update
> + * hole length until the beginning of the delayed extent.
> + */
> + len = min(es.es_lblk - hole_start, len);
> + }
> +
> +insert_hole:
> + /* Put just found gap into cache to speed up subsequent requests */
> + ext_debug(inode, " -> %u:%u\n", hole_start, len);
> + ext4_es_insert_extent(inode, hole_start, len, ~0, EXTENT_STATUS_HOLE);
> +
> + /* Update hole_len to reflect hole size after map->m_lblk */
> + if (hole_start != map->m_lblk)
> + len -= map->m_lblk - hole_start;
> +out:
> + map->m_pblk = 0;
> + map->m_len = min_t(unsigned int, map->m_len, len);
> +}
>
> /*
> * Block allocation/map/preallocation routine for extents based files
> @@ -4179,22 +4215,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
> * we couldn't try to create block if create flag is zero
> */
> if ((flags & EXT4_GET_BLOCKS_CREATE) == 0) {
> - ext4_lblk_t hole_start, hole_len;
> -
> - hole_start = map->m_lblk;
> - hole_len = ext4_ext_determine_hole(inode, path, &hole_start);
> - /*
> - * put just found gap into cache to speed up
> - * subsequent requests
> - */
> - ext4_ext_put_gap_in_cache(inode, hole_start, hole_len);
> -
> - /* Update hole_len to reflect hole size after map->m_lblk */
> - if (hole_start != map->m_lblk)
> - hole_len -= map->m_lblk - hole_start;
> - map->m_pblk = 0;
> - map->m_len = min_t(unsigned int, map->m_len, hole_len);
> -
> + ext4_ext_determine_hole(inode, path, map);
> goto out;
> }
>
> --
> 2.39.2
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-01-03 11:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 12:38 [RFC PATCH v2 00/25] ext4: use iomap for regular file's buffered IO path and enable large foilo Zhang Yi
2024-01-02 12:38 ` [RFC PATCH v2 01/25] ext4: refactor ext4_da_map_blocks() Zhang Yi
2024-01-03 9:56 ` Jan Kara
2024-01-02 12:38 ` [RFC PATCH v2 02/25] ext4: convert to exclusive lock while inserting delalloc extents Zhang Yi
2024-01-03 10:03 ` Jan Kara
2024-01-02 12:38 ` [RFC PATCH v2 03/25] ext4: correct the hole length returned by ext4_map_blocks() Zhang Yi
2024-01-03 11:02 ` Jan Kara [this message]
2024-01-02 12:38 ` [RFC PATCH v2 04/25] ext4: add a hole extent entry in cache after punch Zhang Yi
2024-01-03 11:04 ` Jan Kara
2024-01-02 12:38 ` [RFC PATCH v2 05/25] ext4: make ext4_map_blocks() distinguish delalloc only extent Zhang Yi
2024-01-03 11:31 ` Jan Kara
2024-01-03 13:20 ` Zhang Yi
2024-01-02 12:38 ` [RFC PATCH v2 06/25] ext4: make ext4_set_iomap() recognize IOMAP_DELALLOC map type Zhang Yi
2024-01-03 11:35 ` Jan Kara
2024-01-02 12:39 ` [RFC PATCH v2 07/25] iomap: don't increase i_size if it's not a write operation Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 08/25] iomap: add pos and dirty_len into trace_iomap_writepage_map Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 09/25] ext4: allow inserting delalloc extents with multi-blocks Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 10/25] ext4: correct delalloc extent length Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 11/25] ext4: also mark extent as delalloc if it's been unwritten Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 12/25] ext4: factor out bh handles to ext4_da_get_block_prep() Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 13/25] ext4: use reserved metadata blocks when splitting extent in endio Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 14/25] ext4: introduce seq counter for extent entry Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 15/25] ext4: add a new iomap aops for regular file's buffered IO path Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 16/25] ext4: implement buffered read iomap path Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 17/25] ext4: implement buffered write " Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 18/25] ext4: implement writeback " Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 19/25] ext4: implement mmap " Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 20/25] ext4: implement zero_range " Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 21/25] ext4: writeback partial blocks before zero range Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 22/25] ext4: fall back to buffer_head path for defrag Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 23/25] ext4: partially enable iomap for regular file's buffered IO path Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 24/25] filemap: support disable large folios on active inode Zhang Yi
2024-01-02 12:39 ` [RFC PATCH v2 25/25] ext4: enable large folio for regular file with iomap buffered IO path Zhang Yi
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=20240103110255.7uebqb2iy4jcy6sh@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=chengzhihao1@huawei.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=yi.zhang@huawei.com \
--cc=yi.zhang@huaweicloud.com \
--cc=yukuai3@huawei.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