From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F160CAC597 for ; Thu, 18 Sep 2025 04:56:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:References:MIME-Version:Message-ID:Date:In-Reply-To:To:From:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Yq7+w3Au235z7SJPqHRXvWGjDecji4NaRALvziyEggw=; b=VpQfSHqfMO7GHy95kvWa9mUNir /EMWgqccLw/ntJTd4EtWHv/krtB8KmTJz6aPoflo8DoM0FR4pVDR7x0wXBDUdrkaA1Z9D+XbJ1VAS GkZBtdBD+GqQZynydnJSKEYGYsHK8kVDcJyaG0ukuIz4s7wySzLT5N22/jfOpILqdc7o=; Received: from [127.0.0.1] (helo=sfs-ml-3.v29.lw.sourceforge.com) by sfs-ml-3.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uz6gb-0007wz-NS; Thu, 18 Sep 2025 04:56:01 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-3.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uz6gZ-0007wh-Vd for linux-f2fs-devel@lists.sourceforge.net; Thu, 18 Sep 2025 04:56:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=References:Content-Type:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:In-Reply-To:Cc:To:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zefas1JuGiUdEFTbKhZnv+ZVIOySC9g42o1FgVXKi8U=; b=YNXJqjU2ZlRRwchNV9CKfjEF3v xJ2ofinWXPX+xjEsDIfpwpY7ntLASL7QIBJ0C+UTA/93IkcmcSvQSSxzgBl8bL6teRTWRT5/Zzcbz 06I/OT/IC7vhhfyqzUvA/wDoDrfT9A3/+l6ZQuMreCr/VDNNfuUTQ2kt/RaHuy95ZxvM=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=References:Content-Type:Content-Transfer-Encoding:MIME-Version:Message-ID :Date:Subject:In-Reply-To:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Zefas1JuGiUdEFTbKhZnv+ZVIOySC9g42o1FgVXKi8U=; b=Hi5/JfJUigeT28AcjltBBKI1FJ 6lDVy/795ll8NclQC0qhyYNVF7jppEvrtpOol8qLbAAZttKP4Ioj2wuFHtBG5Ot9/eaZvXqL5KXtj TCG3i94L0gi8tgbmFzWbGYI375IQjZb1ivwWQOmhCqD5qcPCBNIECF0bbUJkrJz7sZLA=; Received: from mailout4.samsung.com ([203.254.224.34]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1uz6gY-0006jr-Qn for linux-f2fs-devel@lists.sourceforge.net; Thu, 18 Sep 2025 04:55:59 +0000 Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20250918045546epoutp043889056b038801e4c89c778f02e80173~mR4ZI1UeG1983519835epoutp040 for ; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20250918045546epoutp043889056b038801e4c89c778f02e80173~mR4ZI1UeG1983519835epoutp040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1758171346; bh=Zefas1JuGiUdEFTbKhZnv+ZVIOySC9g42o1FgVXKi8U=; h=From:To:Cc:In-Reply-To:Subject:Date:References:From; b=CSIr6b7Fi9L/y3bWgOaOXCyXlH0zCSLmyBuhcWL6TA2EJmmwuLHl/slfF80k5VFlv UfLNJ4DCYyuooTJGtTpte4C6JcWFU73xqvO3XDiuAx/MBPTfVjtg0QKSxwHz1lagwE lWe+T1ZAyoNx5CoxCjKLlRpAI8Lxv4TKqJs7+CPk= Received: from epsnrtp02.localdomain (unknown [182.195.42.154]) by epcas1p3.samsung.com (KnoxPortal) with ESMTPS id 20250918045546epcas1p378af9aae47cab22e9f998f4efd2254b6~mR4Y2dbiW2531025310epcas1p3s; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) Received: from epcas1p4.samsung.com (unknown [182.195.38.247]) by epsnrtp02.localdomain (Postfix) with ESMTP id 4cS3HQ1WX0z2SSKX; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) Received: from epsmtip1.samsung.com (unknown [182.195.34.30]) by epcas1p4.samsung.com (KnoxPortal) with ESMTPA id 20250918045545epcas1p4c45f2104438d05dbb02f9cfb92cae8c6~mR4YMpbGq0638406384epcas1p4a; Thu, 18 Sep 2025 04:55:45 +0000 (GMT) Received: from yunji0kang01 (unknown [10.253.100.171]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250918045545epsmtip13d05c5d1c33b18a3a7bef7a56b69ab42~mR4YJVSxw0616806168epsmtip1P; Thu, 18 Sep 2025 04:55:45 +0000 (GMT) From: "Yunji Kang" To: "'Chao Yu'" , In-Reply-To: Date: Thu, 18 Sep 2025 13:55:45 +0900 Message-ID: <000a01dc2858$7e50f460$7af2dd20$@samsung.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGlTO1sK2WH87Ru+8OHbgyt7E/JwJw0GzGAYBuEl+0o/nd0A== Content-Language: ko X-CMS-MailID: 20250918045545epcas1p4c45f2104438d05dbb02f9cfb92cae8c6 X-Msg-Generator: CA CMS-TYPE: 101P cpgsPolicy: CPGSC10-711,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250917055237epcas1p2faa1b3d6555ffc5179c700e7a2afd448 References: <20250917055217.39960-1-yunji0.kang@samsung.com> X-Headers-End: 1uz6gY-0006jr-Qn Subject: Re: [f2fs-dev] [PATCH] f2fs: readahead node block in F2FS_GET_BLOCK_PRECACHE mode X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 'Sungjong Seo' , linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net > > In f2fs_precache_extents(), For large files, It requires reading many > > node blocks. Instead of reading each node block with synchronous I/O, > > this patch applies readahead so that node blocks can be fetched in > > advance. > > > > It reduces the overhead of repeated sync reads and improves efficiency > > when precaching extents of large files. > > > > I created a file with the same largest extent and executed the test. > > For this experiment, I set the file's largest extent with an offset of > > 0 and a size of 1GB. I configured the remaining area with 100MB extents. > > > > 5GB test file: > > dd if=/dev/urandom of=test1 bs=1m count=5120 cp test1 test2 fsync > > test1 dd if=test1 of=test2 bs=1m skip=1024 seek=1024 count=100 > > conv=notrunc dd if=test1 of=test2 bs=1m skip=1224 seek=1224 count=100 > > conv=notrunc ... > > dd if=test1 of=test2 bs=1m skip=5024 seek=5024 count=100 conv=notrunc > > reboot > > > > I also created 10GB and 20GB files with large extents using the same > > method. > > > > ioctl(F2FS_IOC_PRECACHE_EXTENTS) test results are as follows: > > +-----------+---------+---------+-----------+ > > | File size | Before | After | Reduction | > > +-----------+---------+---------+-----------+ > > | 5GB | 101.8ms | 72.1ms | 29.2% | > > | 10GB | 222.9ms | 149.5ms | 32.9% | > > | 20GB | 446.2ms | 276.3ms | 38.1% | > > +-----------+---------+---------+-----------+ > > Tested on a 256GB mobile device with an SM8750 chipset. > > > > Reviewed-by: Sungjong Seo > > Reviewed-by: Sunmin Jeong > > Signed-off-by: Yunji Kang > > --- > > fs/f2fs/data.c | 3 +++ > > fs/f2fs/f2fs.h | 1 + > > fs/f2fs/node.c | 4 +++- > > 3 files changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index > > 7961e0ddfca3..ab3117e3b24a 100644 > > --- a/fs/f2fs/data.c > > +++ b/fs/f2fs/data.c > > @@ -1572,6 +1572,9 @@ int f2fs_map_blocks(struct inode *inode, struct > f2fs_map_blocks *map, int flag) > > pgofs = (pgoff_t)map->m_lblk; > > end = pgofs + maxblocks; > > > > + if (flag == F2FS_GET_BLOCK_PRECACHE) > > + mode = LOOKUP_NODE_PRECACHE; > > + > > next_dnode: > > if (map->m_may_create) { > > if (f2fs_lfs_mode(sbi)) > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index > > 9d3bc9633c1d..3ce41528d48e 100644 > > --- a/fs/f2fs/f2fs.h > > +++ b/fs/f2fs/f2fs.h > > @@ -651,6 +651,7 @@ enum { > > * look up a node with readahead called > > * by get_data_block. > > */ > > + LOOKUP_NODE_PRECACHE, /* look up a node for > F2FS_GET_BLOCK_PRECACHE */ > > }; > > > > #define DEFAULT_RETRY_IO_COUNT 8 /* maximum retry read IO or flush > count */ > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index > > 4254db453b2d..50be167e5c59 100644 > > --- a/fs/f2fs/node.c > > +++ b/fs/f2fs/node.c > > @@ -860,7 +860,9 @@ int f2fs_get_dnode_of_data(struct dnode_of_data *dn, > pgoff_t index, int mode) > > set_nid(parent, offset[i - 1], nids[i], i == 1); > > f2fs_alloc_nid_done(sbi, nids[i]); > > done = true; > > - } else if (mode == LOOKUP_NODE_RA && i == level && level > 1) > { > > + } else if ((mode == LOOKUP_NODE_RA || > > Does this change the logic for mode = LOOKUP_NODE_RA? > > Not sure, do you mean this? > > if ((i == level && level > 1) && > (mode == LOOKUP_NODE_RA || > (mode == LOOKUP_NODE_PRECACHE && > offset[i - 1] % MAX_RA_NODE == 0))) > > Thanks, > > > + (mode == LOOKUP_NODE_PRECACHE && offset[i - 1] % > MAX_RA_NODE == 0)) > > + && i == level && level > 1) { > > nfolio[i] = f2fs_get_node_folio_ra(parent, offset[i - > 1]); > > if (IS_ERR(nfolio[i])) { > > err = PTR_ERR(nfolio[i]); I think the code has the same meaning. The version you wrote looks more readable, so would it be okay if I change the patch with your code? Also, I did not change the logic for mode = LOOKUP_NODE_RA; I only added a condition for when readahead is performed. Thanks. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E76D217A310 for ; Thu, 18 Sep 2025 04:55:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.254.224.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758171354; cv=none; b=Xn91WOibSBveeSYZYPHpEJ/aMrenemqku/VvfOa3ospPbaSeEudCdGHyr7aLv+b/ArC50HJlVcprOyry6oTkMh1nPG8UjFtSdG73VnWeyqxZ64H7CWzMzWLkw182fFvq2URxJlrxk0nrCPQnfq/+R745qDZ6bkj1aKNZ91+iy14= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758171354; c=relaxed/simple; bh=6glWsPn+/Z8BQ0j7MY6JIDYXrf9ocQQxhqphGuoxQbg=; h=From:To:Cc:In-Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Type:References; b=BJVWOA8EM3kWXHQNNT88zqtyhGZqL71wHRY5RHVe0mR9hZqwnAsYQlhZGS1xGtqavtiqct1gppLOx79+7+Flfsor5f1ZqNB0L/LQm3Gy/ynv4N8pYLJnC5iqG8mJjqi9Zp9t9ZaqGBV+sXFX2UHWWHWFM2Fr0Ms9Ch2kkZdL0oI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com; spf=pass smtp.mailfrom=samsung.com; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b=CSIr6b7F; arc=none smtp.client-ip=203.254.224.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=samsung.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=samsung.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="CSIr6b7F" Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20250918045546epoutp02455343bd23e23c96c26437959a09db54~mR4ZI9VTT0060200602epoutp02o for ; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20250918045546epoutp02455343bd23e23c96c26437959a09db54~mR4ZI9VTT0060200602epoutp02o DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1758171346; bh=Zefas1JuGiUdEFTbKhZnv+ZVIOySC9g42o1FgVXKi8U=; h=From:To:Cc:In-Reply-To:Subject:Date:References:From; b=CSIr6b7Fi9L/y3bWgOaOXCyXlH0zCSLmyBuhcWL6TA2EJmmwuLHl/slfF80k5VFlv UfLNJ4DCYyuooTJGtTpte4C6JcWFU73xqvO3XDiuAx/MBPTfVjtg0QKSxwHz1lagwE lWe+T1ZAyoNx5CoxCjKLlRpAI8Lxv4TKqJs7+CPk= Received: from epsnrtp02.localdomain (unknown [182.195.42.154]) by epcas1p3.samsung.com (KnoxPortal) with ESMTPS id 20250918045546epcas1p378af9aae47cab22e9f998f4efd2254b6~mR4Y2dbiW2531025310epcas1p3s; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) Received: from epcas1p4.samsung.com (unknown [182.195.38.247]) by epsnrtp02.localdomain (Postfix) with ESMTP id 4cS3HQ1WX0z2SSKX; Thu, 18 Sep 2025 04:55:46 +0000 (GMT) Received: from epsmtip1.samsung.com (unknown [182.195.34.30]) by epcas1p4.samsung.com (KnoxPortal) with ESMTPA id 20250918045545epcas1p4c45f2104438d05dbb02f9cfb92cae8c6~mR4YMpbGq0638406384epcas1p4a; Thu, 18 Sep 2025 04:55:45 +0000 (GMT) Received: from yunji0kang01 (unknown [10.253.100.171]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250918045545epsmtip13d05c5d1c33b18a3a7bef7a56b69ab42~mR4YJVSxw0616806168epsmtip1P; Thu, 18 Sep 2025 04:55:45 +0000 (GMT) From: "Yunji Kang" To: "'Chao Yu'" , Cc: , , "'Sungjong Seo'" , "'Sunmin Jeong'" In-Reply-To: Subject: RE: [PATCH] f2fs: readahead node block in F2FS_GET_BLOCK_PRECACHE mode Date: Thu, 18 Sep 2025 13:55:45 +0900 Message-ID: <000a01dc2858$7e50f460$7af2dd20$@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGlTO1sK2WH87Ru+8OHbgyt7E/JwJw0GzGAYBuEl+0o/nd0A== Content-Language: ko X-CMS-MailID: 20250918045545epcas1p4c45f2104438d05dbb02f9cfb92cae8c6 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" CMS-TYPE: 101P cpgsPolicy: CPGSC10-711,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250917055237epcas1p2faa1b3d6555ffc5179c700e7a2afd448 References: <20250917055217.39960-1-yunji0.kang@samsung.com> > > In f2fs_precache_extents(), For large files, It requires reading many > > node blocks. Instead of reading each node block with synchronous I/O, > > this patch applies readahead so that node blocks can be fetched in > > advance. > > > > It reduces the overhead of repeated sync reads and improves efficiency > > when precaching extents of large files. > > > > I created a file with the same largest extent and executed the test. > > For this experiment, I set the file's largest extent with an offset of > > 0 and a size of 1GB. I configured the remaining area with 100MB extents= . > > > > 5GB test file: > > dd if=3D/dev/urandom of=3Dtest1 bs=3D1m count=3D5120 cp test1 test2 fsy= nc > > test1 dd if=3Dtest1 of=3Dtest2 bs=3D1m skip=3D1024 seek=3D1024 count=3D= 100 > > conv=3Dnotrunc dd if=3Dtest1 of=3Dtest2 bs=3D1m skip=3D1224 seek=3D1224= count=3D100 > > conv=3Dnotrunc ... > > dd if=3Dtest1 of=3Dtest2 bs=3D1m skip=3D5024 seek=3D5024 count=3D100 co= nv=3Dnotrunc > > reboot > > > > I also created 10GB and 20GB files with large extents using the same > > method. > > > > ioctl(F2FS_IOC_PRECACHE_EXTENTS) test results are as follows: > > +-----------+---------+---------+-----------+ > > =7C File size =7C Before =7C After =7C Reduction =7C > > +-----------+---------+---------+-----------+ > > =7C 5GB =7C 101.8ms =7C 72.1ms =7C 29.2% =7C > > =7C 10GB =7C 222.9ms =7C 149.5ms =7C 32.9% =7C > > =7C 20GB =7C 446.2ms =7C 276.3ms =7C 38.1% =7C > > +-----------+---------+---------+-----------+ > > Tested on a 256GB mobile device with an SM8750 chipset. > > > > Reviewed-by: Sungjong Seo > > Reviewed-by: Sunmin Jeong > > Signed-off-by: Yunji Kang > > --- > > fs/f2fs/data.c =7C 3 +++ > > fs/f2fs/f2fs.h =7C 1 + > > fs/f2fs/node.c =7C 4 +++- > > 3 files changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index > > 7961e0ddfca3..ab3117e3b24a 100644 > > --- a/fs/f2fs/data.c > > +++ b/fs/f2fs/data.c > > =40=40 -1572,6 +1572,9 =40=40 int f2fs_map_blocks(struct inode *inode, = struct > f2fs_map_blocks *map, int flag) > > pgofs =3D (pgoff_t)map->m_lblk; > > end =3D pgofs + maxblocks; > > > > + if (flag =3D=3D F2FS_GET_BLOCK_PRECACHE) > > + mode =3D LOOKUP_NODE_PRECACHE; > > + > > next_dnode: > > if (map->m_may_create) =7B > > if (f2fs_lfs_mode(sbi)) > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index > > 9d3bc9633c1d..3ce41528d48e 100644 > > --- a/fs/f2fs/f2fs.h > > +++ b/fs/f2fs/f2fs.h > > =40=40 -651,6 +651,7 =40=40 enum =7B > > * look up a node with readahead called > > * by get_data_block. > > */ > > + LOOKUP_NODE_PRECACHE, /* look up a node for > F2FS_GET_BLOCK_PRECACHE */ > > =7D; > > > > =23define DEFAULT_RETRY_IO_COUNT 8 /* maximum retry read IO or flush > count */ > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index > > 4254db453b2d..50be167e5c59 100644 > > --- a/fs/f2fs/node.c > > +++ b/fs/f2fs/node.c > > =40=40 -860,7 +860,9 =40=40 int f2fs_get_dnode_of_data(struct dnode_of_= data *dn, > pgoff_t index, int mode) > > set_nid(parent, offset=5Bi - 1=5D, nids=5Bi=5D, i =3D=3D 1); > > f2fs_alloc_nid_done(sbi, nids=5Bi=5D); > > done =3D true; > > - =7D else if (mode =3D=3D LOOKUP_NODE_RA && i =3D=3D level && level >= 1) > =7B > > + =7D else if ((mode =3D=3D LOOKUP_NODE_RA =7C=7C >=20 > Does this change the logic for mode =3D LOOKUP_NODE_RA? >=20 > Not sure, do you mean this? >=20 > if ((i =3D=3D level && level > 1) && > (mode =3D=3D LOOKUP_NODE_RA =7C=7C > (mode =3D=3D LOOKUP_NODE_PRECACHE && > offset=5Bi - 1=5D % MAX_RA_NODE =3D=3D 0))) >=20 > Thanks, >=20 > > + (mode =3D=3D LOOKUP_NODE_PRECACHE && offset=5Bi - 1=5D % > MAX_RA_NODE =3D=3D 0)) > > + && i =3D=3D level && level > 1) =7B > > nfolio=5Bi=5D =3D f2fs_get_node_folio_ra(parent, offset=5Bi - > 1=5D); > > if (IS_ERR(nfolio=5Bi=5D)) =7B > > err =3D PTR_ERR(nfolio=5Bi=5D); I think the code has the same meaning. The version you wrote looks more readable, so would it be okay if I change = the patch with your code? Also, I did not change the logic for mode =3D LOOKUP_NODE_RA; I only added = a condition for when readahead is performed. Thanks.