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

[Christoph Hellwig <hch@infradead.org>]

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