From: Jan Kara <jack@suse.cz>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: Baokun Li <libaokun1@huawei.com>, Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, ritesh.list@gmail.com,
linux-kernel@vger.kernel.org, yi.zhang@huawei.com,
yangerkun@huawei.com, yukuai3@huawei.com, stable@kernel.org
Subject: Re: [PATCH] ext4: correct best extent lstart adjustment logic
Date: Thu, 1 Feb 2024 12:46:14 +0100 [thread overview]
Message-ID: <20240201114614.4jkvi2c6buuovsj7@quack3> (raw)
In-Reply-To: <Zbt7setS4c/Q4fyv@li-bb2b2a4c-3307-11b2-a85c-8fa5c3a69313.ibm.com>
Hi guys!
On Thu 01-02-24 16:38:33, Ojaswin Mujoo wrote:
> Thanks for the CC, I somehow missed this patch.
>
> As described in the discussion Jan linked [1] , there is a known bug in the
> normalize code (which i should probably get back to now ) where we sometimes
> end up with a goal range which doesn't completely cover the original extent and
> this was causing issues when we tried to cover the complete original request in
> the PA window adjustment logic. That and to minimize fragmentation, we ended up
> going with the logic we have right now.
>
> In short, I agree that in the example Baokun pointed out, it is not
> optimal to have to make an allocation request twice when we can get it in
> one go.
>
> I also think Baokun is correct that if keeping the best extent at the end
> doesn't cover the original start, then any other case should not lead to
> it overflowing out of goal extent, including the case where original
> extent is overflowing goal extent.
Right, it was not obvious to me yesterday but when I've now reread how the
normalization shifts the goal window, it is obvious.
> So, as mentioned, it boils down to a trade off between multiple allocations and slightly
> increased fragmentation. iiuc preallocations are anyways dropped when the file closes
> so I think it shouldn't hurt too much fragmentation wise to prioritize less
> allocations. What are your thoughts on this Jan, Baokun?
OK, I'm fine with the Baokun's change if we remove the problematic BUG_ON.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2024-02-01 11:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 12:33 Baokun Li
2024-01-31 12:46 ` Jan Kara
2024-02-01 3:31 ` Baokun Li
2024-02-01 11:08 ` Ojaswin Mujoo
2024-02-01 11:46 ` Jan Kara [this message]
2024-02-01 12:34 ` Baokun Li
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=20240201114614.4jkvi2c6buuovsj7@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=stable@kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.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
all inboxes | Powered by JetHome®