[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aSLoN-oEqS-OpLKE@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Sun, 23 Nov 2025 16:25:51 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: Zhang Yi <yi.zhang@...weicloud.com>
Cc: linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, tytso@....edu, adilger.kernel@...ger.ca,
jack@...e.cz, yi.zhang@...wei.com, yizhang089@...il.com,
libaokun1@...wei.com, yangerkun@...wei.com
Subject: Re: [PATCH v2 00/13] ext4: replace ext4_es_insert_extent() when
caching on-disk extents
On Fri, Nov 21, 2025 at 02:07:58PM +0800, Zhang Yi wrote:
> Changes since v1:
> - Rebase the codes based on the latest linux-next 20251120.
> - Add patches 01-05, fix two stale data problems caused by
Hi Zhang, thanks for the patches.
I've always felt uncomfortable with the ZEROOUT code here because it
seems to have many such bugs as you pointed out in the series. Its very
fragile and the bugs are easy to miss behind all the data valid and
split flags mess.
As per my understanding, ZEROOUT logic seems to be a special best-effort
try to make the split/convert operation "work" when dealing with
transient errors like ENOSPC etc. I was just wondering if it makes sense
to just get rid of the whole ZEROOUT logic completely and just reset the
extent to orig state if there is any error. This allows us to get rid of
DATA_VALID* flags as well and makes the whole ext4_split_convert_extents()
slightly less messy.
Maybe we can have a retry loop at the top level caller if we want to try
again for say ENOSPC or ENOMEM.
Would love to hear your thoughts on it.
Thanks,
Ojaswin
> EXT4_EXT_MAY_ZEROOUT when splitting extent.
> - Add patches 06-07, fix two stale extent status entries problems also
> caused by splitting extent.
> - Modify patches 08-10, extend __es_remove_extent() and
> ext4_es_cache_extent() to allow them to overwrite existing extents of
> the same status when caching on-disk extents, while also checking
> extents of different stauts and raising alarms to prevent misuse.
> - Add patch 13 to clear the usage of ext4_es_insert_extent(), and
> remove the TODO comment in it.
>
> v1: https://lore.kernel.org/linux-ext4/20251031062905.4135909-1-yi.zhang@huaweicloud.com/
>
> Original Description
>
> This series addresses the optimization that Jan pointed out [1]
> regarding the introduction of a sequence number to
> ext4_es_insert_extent(). The proposal is to replace all instances where
> the cache of on-disk extents is updated by using ext4_es_cache_extent()
> instead of ext4_es_insert_extent(). This change can prevent excessive
> cache invalidations caused by unnecessarily increasing the extent
> sequence number when reading from the on-disk extent tree.
>
> [1] https://lore.kernel.org/linux-ext4/ympvfypw3222g2k4xzd5pba4zhkz5jihw4td67iixvrqhuu43y@wse63ntv4s6u/
>
> Cheers,
> Yi.
>
> Zhang Yi (13):
> ext4: cleanup zeroout in ext4_split_extent_at()
> ext4: subdivide EXT4_EXT_DATA_VALID1
> ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1
> ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before
> submitting I/O
> ext4: correct the mapping status if the extent has been zeroed
> ext4: don't cache extent during splitting extent
> ext4: drop extent cache before splitting extent
> ext4: cleanup useless out tag in __es_remove_extent()
> ext4: make __es_remove_extent() check extent status
> ext4: make ext4_es_cache_extent() support overwrite existing extents
> ext4: adjust the debug info in ext4_es_cache_extent()
> ext4: replace ext4_es_insert_extent() when caching on-disk extents
> ext4: drop the TODO comment in ext4_es_insert_extent()
>
> fs/ext4/extents.c | 127 +++++++++++++++++++++++----------------
> fs/ext4/extents_status.c | 121 ++++++++++++++++++++++++++++---------
> fs/ext4/inode.c | 18 +++---
> 3 files changed, 176 insertions(+), 90 deletions(-)
>
> --
> 2.46.1
>
Powered by blists - more mailing lists