mounting 4k blocksize on e.g. 64k hosts

[Gao Xiang]

On 2024/12/7 21:53, Ian Kent wrote:
> On 7/12/24 15:25, Gao Xiang wrote:
>> Hi Ian,
>>
>> On 2024/12/7 09:09, Ian Kent wrote:
>>> On 7/12/24 04:21, Gao Xiang wrote:
>>>>
>>>>
>>>> On 2024/12/7 04:10, Colin Walters wrote:
>>>>> On Fri, Dec 6, 2024, at 2:46 PM, Gao Xiang wrote:
>>>>>
>>>>>> Did you try upstream kernels? It's already supported upstream
>>>>>> since Linux 6.4.
>>>>>
>>>>> Sorry, my bad. (It should have occurred to me to check, but this one popped back up on my radar when I'm trying to do several other things at the same time).
>>>>>
>>>>> Anyways looks like the fix specifically was https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3c4bdcc756e60b95365c66ff58844ce75d1c8f8 ?
>>>>
>>>> Yes, although it has been supported for nearly two
>>>> years, but there are still many dependencies
>>>> against RHEL 9 kernel (5.14) codebase.
>>>>
>>>>>
>>>>>> I think RHEL 9 is lacking of many features.
>>>>>
>>>>> Yes, but I'll try to argue for refresh for 9.6. Thanks!
>>>>> (Just tried to cherry pick that one myself, some conflicts but looks tractable)
>>>>
>>>> Actually, the PR below has been delayed for
>>>> months:
>>>> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/4123
>>>
>>> Indeed, yes.
>>>
>>>
>>> I deferred it because I thought back porting the idmap type changes that came after
>>>
>>> 5.14 was more important and the above MR was conflicting with them.
>>>
>>> That was a large change and was difficult to get merged but it's done now.
>>
>> Thanks for the reply!
>>
>> Yeah, I thought it seems to be delayed due to some
>> other high priority stuffs, but keep the codebase
>> in line with Linux v6.1 or v6.6 is helpful to
>> container use cases since I'm mainly working on
>> this area these years, such as:
>>  - large folios for better read performance;
>>  - subpage block support (>= 512-byte blocks);
>>  - FSDAX for page cache sharing into VMs;
>>  - advanced compression features;
>>  - and more.
> 
> I understand but right now I just want to get that original merge request merged.
> 
> 
> Although, now I'm back to it, and we have a request for something specific, it may
> 
> go further than 5.19. Equally, back porting feature requests will be much more straight
> 
> forward with our RHEL-9 erofs at 5.19 as a basis. We'll need to wait and see what time
> 
> we have available and what the magnitude of the changes are for the request. Whether
> 
> we have tests available for user space and kernel space is a factor as well because
> 
> everything we support needs QE test coverage if at all possible.

Totally understood, and I also agree it'd better to backport to
5.19 as a basis first.

> 
> 
> We also need to focus on the fact that RHEL-10 is in need of work on erofs and is a
> 
> priority atm. I need to spend time there too.
> 
> 
> And I should add I have been trying to find time to get an autofs release out that needs
> 
> to be back ported to both RHEL-9 and RHEL-10 (and I'm running out of time!) and a tricky
> 
> kernel fix to the autofs module as well, and that's not all I have going on.
> 
> 
> Point being, please understand it's not as simple as just doing a back port, there is due
> 
> process to follow which also takes time.

Yeah.

Thanks,
Gao Xiang

> 
> 
> Ian