Re: [PATCH] bpf: add bpf_real_inode() kfunc

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/4/10 15:06, Christoph Hellwig wrote:
> On Fri, Apr 10, 2026 at 02:46:00PM +0800, Gao Xiang wrote:
>>> It needs to be applied in-memory for every changed, and persisted to
>>> disk on every fsync or equivalent operation.
>>
>> Yes, yet it doesn't change my evaluation: and you need
>> to consider background writebacks too (since writeback
>> will update data and then impact the whole hash tree).
>>
>> Currently data writeback can be applied for each block
>> independently, but if you consider maintaining a hash
>> tree (rather than simple checksums), I guess you have
>> to keep strict atomicity between data writeback,
>> metadata and hash-tree writeback, otherwise the hashes
>> and partial writeback data will be mismatched.
> 
> You write the leaf checksum with each block.  The rest of the chain
> leading up to the root is kept in metadata tied to the inode and needs
> to be written atomically with the transaction commit that updates the
> on-disk metadata to point to the newly written block.
> 
>> Yes, the OOB approach for leaf hashes will help to
>> reduce write amplification, but my current observation
>> is that it won't have any help to read amplification,
>> especially for small random read; overall it depends
>> on the target workload.
> 
> For HDD is roughly halves the number of seeks for random reads, and
> at least significantly reduces it significantly but quite a bit
> less.  For SSD it reduces the IOPS in a similar way, but for that

Yes, seeks can be reduced and if all related leaf block
hashes can be loaded in a single request (even some main
data blocks may not needed) it will help more; in
practice, a POC forming out to measure the numbers between
hashing in individual blocks or extended area may help to
get more detailed ideas.

If it's useful, I think dm-verity can work out in this way
too as a bogus as long as the device supports it (and
converting between these two metadata formats should be
trivial.)

> you need to max out the IOPS, which for most workloads you won't
> on anything currently (and probably in the future) using erofs.

The problem is not always maximum IOPS (I also suspect
there is such real long-term max-IOPS workload too), but
small random burst I/Os with low latencies is what we
usually care much for typical use cases.

Thanks,
Gao Xiang