Re: [RFC PATCH 1/8] fat: support FIEMAP

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br> writes:

> On Thu, Nov 12, 2026 at 02:03:45PM +0900, OGAWA Hirofumi wrote:
>>Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br> writes:
>>
>>
>>[...]
>>
>>>>>  	if (fat_cache_lookup(inode, cluster, &cid, fclus, dclus) < 0) {
>>>>> -		/*
>>>>> -		 * dummy, always not contiguous
>>>>> -		 * This is reinitialized by cache_init(), later.
>>>>> -		 */
>>>>> -		cache_init(&cid, -1, -1);
>>>>> +		/* Cache the contiguous prefix from the known first cluster. */
>>>>> +		cache_init(&cid, 0, *dclus);
>>>>
>>>>Doesn't this add a needless cache? 0 is cached in the inode itself,
>>>>isn't it? (and can be waste small fatent cache slots?)
>>>>
>>>
>>> This is mostly for caching the number of contiguous clusters starting
>>> from 0. i_start only really tells us the first cluster of the file. I'm
>>> not exactly sure of the best way to approach this, though. I guess we
>>> can skip caching when its a one cluster range in this case?
>>>
>>> What do you think?
>>
>>Ah, sure. I think because it is fat_cache_lookup() and stuff are
>>implemented for nr_cont == 1. So I think better way would be supporting
>>the range lookup in whole cache stuff. (however, it can be relatively
>>complex)
>>
>>Thanks.
>>
>
> It seems like exfat had to solve a similar problem a while back:
> https://lore.kernel.org/linux-fsdevel/20260114121250.615064-1-chizhiling@163.com/
>
> Maybe I can work on porting some of that to fat. Would you rather it be
> in a separate series or just add it to the iomap series?

It would be good to add with introducing nr_cont, so iomap is fine.

Maybe looks like exfat implementation doesn't handle rare case. It would
be assuming next cache is not contiguous. Actually next cache can be
contiguous.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>