Re: [PATCH RFC 00/10] btrfs: new performance-based chunk allocation using device roles

[Anand Jain <anand.jain@oracle.com>]

On 30/5/25 08:15, Jani Partanen wrote:
> On 12/05/2025 21.07, Anand Jain wrote:
>> In host hardware, devices can have different speeds. Generally, faster
>> devices come with lesser capacity while slower devices come with larger
>> capacity. A typical configuration would expect that:
>>
>>   - A filesystem's read/write performance is evenly distributed on 
>> average
>>   across the entire filesystem. This is not achievable with the current
>>   allocation method because chunks are allocated based only on device 
>> free
>>   space.
>>
>>   - Typically, faster devices are assigned to metadata chunk allocations
>>   while slower devices are assigned to data chunk allocations.
> 
> Now if this could be expanded to allow tagging fast drives as write- 
> cache, example I would add 256GB nvme drives or partitions as write- 
> cache so even with HDD's as main data storage, I would get very fast 
> writing.
> 
> Ofcourse cache would need some task to empty it after x time or it would 
> have not much use. This is currently issue with lvm caching. There is 2 
> type of caches, one is for read/write but when cache is full, it has not 
> much help for writes anymore because it filled with read cache. Another 
> is just write-cache.
>

Thanks for the feedback. A write-cache device is quite different from
data or metadata devices in the kernel. I’ll look into it once the chunk
allocation part is settled.

 From a UI point of view, write-cache could be treated as another role.
With the current mkfs.btrfs device option scheme, we could add it as an
additional role alongside metadata and data.

Thanks, Anand