mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Daeho Jeong <daeho43@gmail.com>
Cc: jaegeuk@kernel.org, Daeho Jeong <daehojeong@google.com>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 1/4] f2fs: fix blkofs_end correctly in f2fs_migrate_blocks()
Date: Fri, 1 Mar 2024 09:55:14 +0800	[thread overview]
Message-ID: <3325fdb0-1f21-4ba9-919a-09fa0206f7c5@kernel.org> (raw)
In-Reply-To: <CACOAw_yn4m+nEGMEX8RL1xFEaZpzXvjUhUdSoo9d2EeGfzPrAA@mail.gmail.com>

On 2024/3/1 1:41, Daeho Jeong wrote:
> On Thu, Feb 29, 2024 at 2:11 AM Chao Yu <chao@kernel.org> wrote:
>>
>> Jaegeuk, Daeho,
>>
>> Any comments on this serials?
>>
>> Thanks,
> 
> No functional difference here, since start_blk is always aligned with
> the section address.

You're right.

> However, this is more clear in itself.

Thanks for the review!

One more thing is, I found that fallocate() on pinned file will preallocate
aligned w/ section-size which is about several hundred megabyte for ZUFS case,
since commit e1175f022911 ("f2fs: fix to align to section for fallocate() on
pinned file").

It looks not make sense, especially for logcat case which actually want to
preallocate 2MB space, so, what about reverting commit e1175f022911 and
looking for other solution to avoid GCing on fragmented pinned file.

What do you think?

Thanks,

> 
> Reviewed-by: Daeho Jeong <daehojeong@google.com>
> 
> Thanks,
> 
>>
>> On 2024/2/26 9:32, Chao Yu wrote:
>>> In f2fs_migrate_blocks(), when traversing blocks in last section,
>>> blkofs_end should be (start_blk + blkcnt - 1) % blk_per_sec, fix it.
>>>
>>> Signed-off-by: Chao Yu <chao@kernel.org>
>>> ---
>>>    fs/f2fs/data.c | 5 +++--
>>>    1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index c21b92f18463..0c728e82d936 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -3841,13 +3841,14 @@ static int f2fs_migrate_blocks(struct inode *inode, block_t start_blk,
>>>        struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>>>        unsigned int blkofs;
>>>        unsigned int blk_per_sec = BLKS_PER_SEC(sbi);
>>> +     unsigned int end_blk = start_blk + blkcnt - 1;
>>>        unsigned int secidx = start_blk / blk_per_sec;
>>>        unsigned int end_sec;
>>>        int ret = 0;
>>>
>>>        if (!blkcnt)
>>>                return 0;
>>> -     end_sec = secidx + (blkcnt - 1) / blk_per_sec;
>>> +     end_sec = end_blk / blk_per_sec;
>>>
>>>        f2fs_down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
>>>        filemap_invalidate_lock(inode->i_mapping);
>>> @@ -3857,7 +3858,7 @@ static int f2fs_migrate_blocks(struct inode *inode, block_t start_blk,
>>>
>>>        for (; secidx <= end_sec; secidx++) {
>>>                unsigned int blkofs_end = secidx == end_sec ?
>>> -                     (blkcnt - 1) % blk_per_sec : blk_per_sec - 1;
>>> +                             end_blk % blk_per_sec : blk_per_sec - 1;
>>>
>>>                f2fs_down_write(&sbi->pin_sem);
>>>
>>
>>
>> _______________________________________________
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2024-03-01  1:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26  1:32 Chao Yu
2024-02-26  1:32 ` [PATCH 2/4] f2fs: relocate f2fs_precache_extents() in f2fs_swap_activate() Chao Yu
2024-02-29 17:41   ` [f2fs-dev] " Daeho Jeong
2024-02-26  1:32 ` [PATCH 3/4] f2fs: clean up new_curseg() Chao Yu
2024-02-29 17:58   ` [f2fs-dev] " Daeho Jeong
2024-02-26  1:32 ` [PATCH 4/4] f2fs: fix to reset fields for unloaded curseg Chao Yu
2024-02-29 18:07   ` [f2fs-dev] " Daeho Jeong
2024-02-29 10:09 ` [PATCH 1/4] f2fs: fix blkofs_end correctly in f2fs_migrate_blocks() Chao Yu
2024-02-29 17:41   ` [f2fs-dev] " Daeho Jeong
2024-03-01  1:55     ` Chao Yu [this message]
2024-03-01  1:58       ` Jaegeuk Kim
2024-03-04 18:20 ` patchwork-bot+f2fs

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=3325fdb0-1f21-4ba9-919a-09fa0206f7c5@kernel.org \
    --to=chao@kernel.org \
    --cc=daeho43@gmail.com \
    --cc=daehojeong@google.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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®