mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chi Zhiling <chizhiling@163.com>
To: "Yuezhang.Mo@sony.com" <Yuezhang.Mo@sony.com>
Cc: "brauner@kernel.org" <brauner@kernel.org>,
	"chizhiling@kylinos.cn" <chizhiling@kylinos.cn>,
	"jack@suse.cz" <jack@suse.cz>,
	"linkinjeon@kernel.org" <linkinjeon@kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sj1557.seo@samsung.com" <sj1557.seo@samsung.com>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"willy@infradead.org" <willy@infradead.org>
Subject: Re: [PATCH v1 9/9] exfat: support multi-cluster for exfat_get_cluster
Date: Wed, 31 Dec 2025 10:35:11 +0800	[thread overview]
Message-ID: <d832364d-02e6-458d-9eb2-442e1452a0f9@163.com> (raw)
In-Reply-To: <PUZPR04MB6316194114D39A6505BA45A381BCA@PUZPR04MB6316.apcprd04.prod.outlook.com>

On 12/30/25 17:06, Yuezhang.Mo@sony.com wrote:
>> @@ -243,6 +244,7 @@ int exfat_get_cluster(struct inode *inode, unsigned int cluster,
>>        struct buffer_head *bh = NULL;
>>        struct exfat_cache_id cid;
>>        unsigned int content, fclus;
>> +     unsigned int end = (*count <= 1) ? cluster : cluster + *count - 1;
> 
> In exfat_get_block,  count is set as follows:
> 
> count = EXFAT_B_TO_CLU_ROUND_UP(bh_result->b_size, sbi);
> 
> So '*count' is always greater than or equal to 1, the above condition seems unnecessary.


Yes, it is unnecessary.

> 
>> --- a/fs/exfat/inode.c
>> +++ b/fs/exfat/inode.c
>> @@ -134,6 +134,7 @@ static int exfat_map_cluster(struct inode *inode, unsigned int clu_offset,
>>        struct exfat_inode_info *ei = EXFAT_I(inode);
>>        unsigned int local_clu_offset = clu_offset;
>>        unsigned int num_to_be_allocated = 0, num_clusters;
>> +     unsigned int hint_count = max(*count, 1);
> 
> Same as above, hint_count seems unnecessary.
> 
>> +     /*
>> +      * Return on cache hit to keep the code simple.
>> +      */
>> +     if (fclus == cluster) {
>> +             *count = cid.fcluster + cid.nr_contig - fclus + 1;
>>                return 0;
> 
> If 'cid.fcluster + cid.nr_contig - fclus + 1 < *count', how about continuing to collect clusters?
> The following clusters may be continuous.

I'm glad you noticed this detail. It is necessary to explain this and 
update it in the code comments.

The main reason why I didn't continue the collection was that the 
subsequent clusters might also exist in the cache. This requires us to 
search the cache again to confirm this, and this action might introduce 
additional performance overhead.

I think we can continue to collect, but we need to check the cache 
before doing so.

> 
>> +             while (fclus < end) {
>> +                     if (exfat_ent_get(sb, clu, &content, &bh))
>> +                             goto err;
>> +                     if (++clu != content) {
>> +                             /* TODO: read ahead if content valid */
>> +                             break;
> 
> The next cluster index has been read and will definitely be used.
> How about add it to the cache?

Good idea!
will add it in v2,

thanks,

> 


  reply	other threads:[~2025-12-31  2:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-30  9:06 Yuezhang.Mo
2025-12-31  2:35 ` Chi Zhiling [this message]
2026-01-04  7:56   ` Yuezhang.Mo
2026-01-05  2:58     ` Chi Zhiling
2026-01-06  7:32       ` Yuezhang.Mo
2026-01-06  8:45         ` Chi Zhiling
  -- strict thread matches above, loose matches on Subject: below --
2025-12-26  9:44 [PATCH v1 0/9] Enable exfat_get_block to support obtaining multiple clusters Chi Zhiling
2025-12-26  9:44 ` [PATCH v1 9/9] exfat: support multi-cluster for exfat_get_cluster Chi Zhiling

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=d832364d-02e6-458d-9eb2-442e1452a0f9@163.com \
    --to=chizhiling@163.com \
    --cc=Yuezhang.Mo@sony.com \
    --cc=brauner@kernel.org \
    --cc=chizhiling@kylinos.cn \
    --cc=jack@suse.cz \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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®